2018-12-18  Mark Lam  <mark.lam@apple.com>

        JSPropertyNameEnumerator should cache the iterated object's structure only after getting its property names.
        https://bugs.webkit.org/show_bug.cgi?id=192464
        <rdar://problem/46519455>

        Reviewed by Saam Barati.

        This is because the process of getting its property names may cause some lazy
        properties to be reified, and the structure will change.  This is needed in order
        for get_direct_pname to work correctly.

        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):

2017-10-03  Saam Barati  <sbarati@apple.com>

        Implement polymorphic prototypes
        https://bugs.webkit.org/show_bug.cgi?id=176391

        Reviewed by Filip Pizlo.

        This patch changes JSC's object model with respect to where the prototype
        of an object is stored. Previously, it was always stored as
        a constant value inside Structure. So an object's structure used to
        always tell you what its prototype is. Anytime an object changed
        its prototype, it would do a structure transition. This enables
        a large class of optimizations: just by doing a structure check,
        we know what the prototype is.
        
        However, this design falls down when you have many objects that
        have the same shape, but only differ in what their prototype value
        is. This arises in many JS programs. A simple, and probably common, example
        is when the program has a constructor inside of a function:
        ```
        function foo() {
            class C {
                constructor() { this.field1 = 42; ...; this.fieldN = 42; }
                method1() { doStuffWith(this.field); }
                method2() { doStuffWith(this.field); }
            }
            let c = new C;
            do things with c;
            }
        repeatedly call foo() here.
        ```
        
        Before this patch, in the above program, each time `new C` created an
        object, it would create an object with a different structure. The
        reason for this is that each time foo is called, there is a new
        instance of C.prototype. However, each `new C` that was created
        with have identical shape sans its prototype value. This would
        cause all ICs that used `c` to quickly give up on any form of caching
        because they would see too many structures and give up and permanently
        divert control flow to the slow path.
        
        This patch fixes this issue by expanding the notion of where the prototype
        of an object is stored. There are now two notions of where the prototype
        is stored. A Structure can now be in two modes:
        1. Mono proto mode. This is the same mode as we used to have. It means
        the structure itself has a constant prototype value.
        2. Poly proto mode. This means the structure knows nothing about the
        prototype value itself. Objects with this structure store their prototype
        in normal object field storage. The structure will tell you the offset of
        this prototype inside the object's storage. As of today, we only reserve
        inline slots for the prototype field because poly proto only occurs
        for JSFinalObject. However, this will be expanded to support out of line
        offsets in a future patch when we extend poly proto to work when we inherit
        from builtin types like Map and Array.
        
        In this initial patch, we do poly proto style inline caching whenever
        we see an object that is poly proto or if an object in its prototype lookup
        chain is poly proto. Poly proto ICs work by verifying the lookup chain
        at runtime. This essentially boils down to performing structure checks
        up the prototype chain. In a future patch, we're going to extend object
        property condition set to work with objects that don't have poly proto bases.
        
        Initially, accesses that have poly proto access chains will always turn
        into GetById/PutById in the DFG. In a future patch, I'm going to teach
        the DFG how to inline certain accesses that have poly proto in the access
        chain.
        
        One of most interesting parts about this patch is how we decide when to go
        poly proto. This patch uses a profiling based approach. An IC will inform
        a watchpoint that it sees an opportunity when two Structure's are structurally
        the same, sans the base object's prototype. This means that two structures
        have equivalent shapes all the way up the prototype chain. To support fast
        structural comparison, we compute a hash for a structure based on the properties
        it has. We compute this hash as we add properties to the structure. This
        computation is nearly free since we always add UniquedStringImpl*'s which
        already have their hashes computed. To compare structural equivalence, we
        just compare hash values all the way up the prototype chain. This means we
        can get hash conflicts between two structures, but it's extremely rare. First,
        it'll be rare for two structures to have the same hash. Secondly, we only
        consider structures originating from the same executable.
        
        How we set up this poly proto watchpoint is crucial to its design. When we create_this
        an object originating from some executable, that executable will create a Box<InlineWatchpointSet>.
        Each structure that originates from this executable will get a copy of that
        Box<InlineWatchpointSet>. As that structure transitions to new structures,
        they too will get a copy of that Box<InilneWatchpointSet>. Therefore, when
        invalidating an arbitrary structure's poly proto watchpoint, we will know
        the next time we create_this from that executable that it had been
        invalidated, and that we should create an object with a poly proto
        structure. We also use the pointer value of this Box<InlineWatchpointSet>
        to determine if two structures originated from the same executable. This
        pruning will severely limit the chances of getting a hash conflict in practice.
        
        This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider.
        It may be a 1-2% ARES-6 progression.
        
        This patch is between neutral and a 9x progression on the various tests
        I added. Most of the microbenchmarks are progressed by at least 50%.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.cpp:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        (JSC::BuiltinNames::underscoreProtoPrivateName const):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::create):
        (JSC::AccessCase::commit):
        (JSC::AccessCase::guardedByStructureCheck const):
        (JSC::AccessCase::canReplace const):
        (JSC::AccessCase::dump const):
        (JSC::AccessCase::visitWeak const):
        (JSC::AccessCase::propagateTransitions const):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * bytecode/AccessCase.h:
        (JSC::AccessCase::usesPolyProto const):
        (JSC::AccessCase::AccessCase):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
        (JSC::GetterSetterAccessCase::create):
        * bytecode/GetterSetterAccessCase.h:
        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
        * bytecode/IntrinsicGetterAccessCase.h:
        * bytecode/ModuleNamespaceAccessCase.cpp:
        (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
        * bytecode/ObjectAllocationProfile.cpp: Added.
        (JSC::ObjectAllocationProfile::initializeProfile):
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::clear):
        (JSC::ObjectAllocationProfile::initialize): Deleted.
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
        * bytecode/ObjectPropertyConditionSet.cpp:
        * bytecode/PolyProtoAccessChain.cpp: Added.
        (JSC::PolyProtoAccessChain::create):
        (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const):
        (JSC::PolyProtoAccessChain::operator== const):
        (JSC::PolyProtoAccessChain::dump const):
        * bytecode/PolyProtoAccessChain.h: Added.
        (JSC::PolyProtoAccessChain::clone):
        (JSC::PolyProtoAccessChain:: const):
        (JSC::PolyProtoAccessChain::operator!= const):
        (JSC::PolyProtoAccessChain::forEach const):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::regenerate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationResult::shouldResetStub const):
        (JSC::AccessGenerationState::AccessGenerationState):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        * bytecode/ProxyableAccessCase.cpp:
        (JSC::ProxyableAccessCase::ProxyableAccessCase):
        (JSC::ProxyableAccessCase::create):
        * bytecode/ProxyableAccessCase.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::canDoFastSpread):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * jsc.cpp:
        (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
        (WTF::DOMJITGetterBaseJSObject::createStructure):
        (WTF::DOMJITGetterBaseJSObject::create):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetterBaseJSObject::customGetter):
        (WTF::DOMJITGetterBaseJSObject::finishCreation):
        (GlobalObject::finishCreation):
        (functionCreateDOMJITGetterBaseJSObject):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayPrototype.cpp:
        (JSC::holesMustForwardToPrototype):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncReverse):
        (JSC::moveElements):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createWithMachineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::visitChildren):
        * runtime/FunctionExecutable.h:
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::initializeObjectAllocationProfile):
        * runtime/FunctionRareData.h:
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructureSlow):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canFastCopy):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure const):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::prototypeForConstruction):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSFunction.h:
        * runtime/JSMap.cpp:
        (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
        (JSC::JSMap::canCloneFastAndNonObservable):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::ensureInt32Slow):
        (JSC::JSObject::ensureDoubleSlow):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC::JSObject::setPrototypeDirect):
        (JSC::JSObject::ordinaryToPrimitive const):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::getEnumerableLength):
        (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
        (JSC::JSObject::prototypeChainMayInterceptStoreTo):
        (JSC::JSObject::needsSlowPutIndexing const):
        (JSC::JSObject::suggestedArrayStorageTransition const):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::getPrototypeDirect const):
        (JSC::JSObject::getPropertySlot):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        (JSC::JSObject::putInlineForJSObject):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
        (JSC::JSSet::canCloneFastAndNonObservable):
        * runtime/LazyClassStructure.h:
        (JSC::LazyClassStructure::prototypeConcurrently const): Deleted.
        * runtime/Operations.cpp:
        (JSC::normalizePrototypeChain):
        * runtime/Operations.h:
        * runtime/Options.h:
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::create):
        (JSC::Structure::holesMustForwardToPrototype const):
        (JSC::Structure::changePrototypeTransition):
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::toStructureShape):
        (JSC::Structure::dump const):
        (JSC::Structure::canCachePropertyNameEnumerator const):
        (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted.
        (JSC::Structure::needsSlowPutIndexing const): Deleted.
        (JSC::Structure::suggestedArrayStorageTransition const): Deleted.
        (JSC::Structure::prototypeForLookup const): Deleted.
        (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted.
        (JSC::Structure::canUseForAllocationsOf): Deleted.
        * runtime/Structure.h:
        * runtime/StructureChain.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::create):
        (JSC::Structure::storedPrototypeObject const):
        (JSC::Structure::storedPrototypeStructure const):
        (JSC::Structure::storedPrototype const):
        (JSC::prototypeForLookupPrimitiveImpl):
        (JSC::Structure::prototypeForLookup const):
        (JSC::Structure::prototypeChain const):
        (JSC::Structure::isValid const):
        (JSC::Structure::add):
        (JSC::Structure::setPropertyTable):
        (JSC::Structure::shouldConvertToPolyProto):
        * runtime/StructureRareData.h:
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        * runtime/TypeSet.h:
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase<Unknown>::isInt32 const):

2018-12-10  Mark Lam  <mark.lam@apple.com>

        Cherry-pick r239062. rdar://problem/46603464

    2018-12-10  Mark Lam  <mark.lam@apple.com>

            PropertyAttribute needs a CustomValue bit.
            https://bugs.webkit.org/show_bug.cgi?id=191993
            <rdar://problem/46264467>

            Reviewed by Saam Barati.

            This is because GetByIdStatus needs to distinguish CustomValue properties from
            other types, and its only means of doing so is via the property's attributes.
            Previously, there's nothing in the property's attributes that can indicate that
            the property is a CustomValue.

            We fix this by doing the following:

            1. Added a PropertyAttribute::CustomValue bit.
            2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is
               CustomAccessor | CustomValue.

            3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(),
               we added a check in JSObject::putDirectCustomAccessor() to see if the attributes
               bits include PropertyAttribute::CustomAccessor.  If not, then the property
               must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit
               to the attributes bits.

               This ensures that the property attributes is sufficient to tell us if the
               property contains a CustomGetterSetter.

            4. Updated all checks for PropertyAttribute::CustomAccessor to check for
               PropertyAttribute::CustomAccessorOrValue instead if their intent is to check
               for the presence of a CustomGetterSetter as opposed to checking specifically
               for one that is used as a CustomAccessor.

               This includes all the Structure transition code that needs to capture the
               attributes change when a CustomValue has been added.

            5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor.
               The fact that we're using a CustomGetterSetter as a CustomValue should remain
               invisible to the descriptor.  This is because the descriptor should describe
               a CustomValue no differently from a plain value.

            6. Added some asserts to ensure that property attributes are as expected, and to
               document some invariants.

            * bytecode/GetByIdStatus.cpp:
            (JSC::GetByIdStatus::computeFromLLInt):
            (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
            (JSC::GetByIdStatus::computeFor):
            * bytecode/InByIdStatus.cpp:
            (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
            * bytecode/PropertyCondition.cpp:
            (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
            * bytecode/PutByIdStatus.cpp:
            (JSC::PutByIdStatus::computeFor):
            * runtime/JSFunction.cpp:
            (JSC::getCalculatedDisplayName):
            * runtime/JSObject.cpp:
            (JSC::JSObject::putDirectCustomAccessor):
            (JSC::JSObject::putDirectNonIndexAccessor):
            (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
            * runtime/JSObject.h:
            (JSC::JSObject::putDirectIndex):
            (JSC::JSObject::fillCustomGetterPropertySlot):
            (JSC::JSObject::putDirect):
            * runtime/JSObjectInlines.h:
            (JSC::JSObject::putDirectInternal):
            * runtime/PropertyDescriptor.cpp:
            (JSC::PropertyDescriptor::setDescriptor):
            (JSC::PropertyDescriptor::setCustomDescriptor):
            (JSC::PropertyDescriptor::setAccessorDescriptor):
            * runtime/PropertySlot.h:
            (JSC::PropertySlot::setCustomGetterSetter):

2018-09-06  Mark Lam  <mark.lam@apple.com>

        Gardening: only visit m_cachedStructureID if it's not null.
        https://bugs.webkit.org/show_bug.cgi?id=189124
        <rdar://problem/43863605>

        Not reviewed.

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::visitChildren):

2018-09-05  Mark Lam  <mark.lam@apple.com>

        JSPropertyNameEnumerator::visitChildren() needs to visit its m_cachedStructureID.
        https://bugs.webkit.org/show_bug.cgi?id=189124
        <rdar://problem/43863605>

        Reviewed by Filip Pizlo.

        It is assumed that the Structure for the m_cachedStructureID will remain alive
        while the m_cachedStructureID is in use.  This prevents the structureID from being
        re-used for a different Structure.

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::visitChildren):

2018-10-15  Saam Barati  <sbarati@apple.com>

        JSArray::shiftCountWithArrayStorage is wrong when an array has holes
        https://bugs.webkit.org/show_bug.cgi?id=190262
        <rdar://problem/44986241>

        Reviewed by Mark Lam.

        We would take the fast path for shiftCountWithArrayStorage when the array
        hasHoles(). However, the code for this was wrong. It'd incorrectly update
        ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage
        path is never taken in JetStream 2, this patch just removes that from
        the fast path. Instead, we just fallback to the slow path when hasHoles().
        If we find evidence that this matters for real use cases, we can
        figure out a way to make the fast path work.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithArrayStorage):

2018-09-07  Mark Lam  <mark.lam@apple.com>

        Ensure that handleIntrinsicCall() is only applied on op_call shaped instructions.
        https://bugs.webkit.org/show_bug.cgi?id=189317
        <rdar://problem/44152198>

        Reviewed by Filip Pizlo.

        handleIntrinsicCall() is normally used for checking if an op_call is a call to
        an intrinsic function, and inlining it if it's a match.

        However, getter and setter functions also does calls, and uses handleCall()
        to implement the call.  handleCall() eventually calls handleIntrinsicCall() to
        check for intrinsics.  This results in a bug because handleIntrinsicCall()
        sometimes relies on the ArrayProfile* of the instruction, and is always assuming
        that the instruction is op_call shaped.  This turns out to be not true: getters
        and setters can get there with op_get_by_val and op_put_by_val instead.

        Since the intrinsic functions handled by handleIntrinsicCall() are never
        intended to be used as getter / setter functions anyway, we can prevent this
        whole class of bugs by having handleIntrinsicCall() fail early if the
        instruction is not op_call shaped.

        To implement this fix, we did the following:

        1. Introduced the OpcodeShape enum.
        2. Introduced isOpcodeShape<OpcodeShape>() for testing if a instruction of the
           shape of the specified OpcodeShape.
        3. Introduced arrayProfileFor<OpcodeShape>() for fetching the ArrayProfile* from
           the instruction given the OpcodeShape.

           Using this arrayProfileFor template has the following benefits:
           1. Centralizes the definition of which instructions has an ArrayProfile* operand.
           2. Centralizes the definition of which operand is the ArrayProfile*.
           3. Asserts that the instruction is of the expected shape when retrieving the
              ArrayProfile*.

        4. Added ArrayProfile::m_typeName and ArrayProfile::s_typeName which are used
           in ArrayProfile::isValid() as a sanity check that a retrieved ArrayProfile*
           indeed does point to an ArrayProfile.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArrayProfile.cpp:
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::isValid const):
        * bytecode/OpcodeInlines.h: Added.
        (JSC::isOpcodeShape):
        (JSC::arrayProfileFor):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_has_indexed_property):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_has_indexed_property):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::getByVal):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2018-07-26  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r234269. rdar://problem/42650430

    arrayProtoPrivateFuncConcatMemcpy() should handle copying from an Undecided type array.
    https://bugs.webkit.org/show_bug.cgi?id=188065
    <rdar://problem/42515726>
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * stress/regress-188065.js: Added.
    
    Source/JavaScriptCore:
    
    * runtime/ArrayPrototype.cpp:
    (JSC::clearElement):
    (JSC::copyElements):
    (JSC::arrayProtoPrivateFuncConcatMemcpy):
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@234269 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-07-26  Mark Lam  <mark.lam@apple.com>

            arrayProtoPrivateFuncConcatMemcpy() should handle copying from an Undecided type array.
            https://bugs.webkit.org/show_bug.cgi?id=188065
            <rdar://problem/42515726>

            Reviewed by Saam Barati.

            * runtime/ArrayPrototype.cpp:
            (JSC::clearElement):
            (JSC::copyElements):
            (JSC::arrayProtoPrivateFuncConcatMemcpy):

2017-05-19  Filip Pizlo  <fpizlo@apple.com>

        Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy
        https://bugs.webkit.org/show_bug.cgi?id=172382

        Reviewed by Saam Barati.
        
        This is just a small clean-up - my last patch here created some unnecessary code duplication.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy):

2017-05-19  Filip Pizlo  <fpizlo@apple.com>

        arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided
        https://bugs.webkit.org/show_bug.cgi?id=172369

        Reviewed by Mark Lam.

        * heap/Subspace.cpp: Reshaped the code a bit to aid debugging.
        (JSC::Subspace::allocate):
        (JSC::Subspace::tryAllocate):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug!
        * runtime/ObjectInitializationScope.cpp: Provide even better feedback.
        (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):

2016-08-31  Filip Pizlo  <fpizlo@apple.com>

        Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
        https://bugs.webkit.org/show_bug.cgi?id=160125

        Reviewed by Geoffrey Garen and Keith Miller.

        In order to make the GC concurrent (bug 149432), we would either need to enable concurrent
        copying or we would need to not copy. Concurrent copying carries a 1-2% throughput overhead
        from the barriers alone. Considering that MarkedSpace does a decent job of avoiding
        fragmentation, it's unlikely that it's worth paying 1-2% throughput for copying. So, we want
        to get rid of copied space. This change moves copied space's biggest client over to marked
        space.
        
        Moving butterflies to marked space means having them use the new Auxiliary HeapCell
        allocation path. This is a fairly mechanical change, but it caused performance regressions
        everywhere, so this change also fixes MarkedSpace's performance issues.
        
        At a high level the mechanical changes are:
        
        - We use AuxiliaryBarrier instead of CopyBarrier.
        
        - We use tryAllocateAuxiliary instead of tryAllocateStorage. I got rid of the silly
          CheckedBoolean stuff, since it's so much more trouble than it's worth.
        
        - The JITs have to emit inlined marked space allocations instead of inline copy space
          allocations.
        
        - Everyone has to get used to zeroing their butterflies after allocation instead of relying
          on them being pre-zeroed by the GC. Copied space would zero things for you, while marked
          space doesn't.
        
        That's about 1/3 of this change. But this led to performance problems, which I fixed with
        optimizations that amounted to a major MarkedSpace rewrite:
        
        - MarkedSpace always causes internal fragmentation for array allocations because the vector
          length we choose when we resize usually leads to a cell size that doesn't correspond to any
          size class. I got around this by making array allocations usually round up vectorLength to
          the maximum allowed by the size class that we would have allocated in. Also,
          ensureLengthSlow() and friends first make sure that the requested length can't just be
          fulfilled with the current allocation size. This safeguard means that not every array
          allocation has to do size class queries. For example, the fast path of new Array(length)
          never does any size class queries, under the assumption that (1) the speed gained from
          avoiding an ensureLengthSlow() call, which then just changes the vectorLength by doing the
          size class query, is too small to offset the speed lost by doing the query on every
          allocation and (2) new Array(length) is a pretty good hint that resizing is not very
          likely.
        
        - Size classes in MarkedSpace were way too precise, which led to external fragmentation. This
          changes MarkedSpace size classes to use a linear progression for very small sizes followed
          by a geometric progression that naturally transitions to a hyperbolic progression. We want
          hyperbolic sizes when we get close to blockSize: for example the largest size we want is
          payloadSize / 2 rounded down, to ensure we get exactly two cells with minimal slop. The
          next size down should be payloadSize / 3 rounded down, and so on. After the last precise
          size (80 bytes), we proceed using a geometric progression, but round up each size to
          minimize slop at the end of the block. This naturally causes the geometric progression to
          turn hyperbolic for large sizes. The size class configuration happens at VM start-up, so
          it can be controlled with runtime options. I found that a base of 1.4 works pretty well.
        
        - Large allocations caused massive internal fragmentation, since the smallest large
          allocation had to use exactly blockSize, and the largest small allocation used
          blockSize / 2. The next size up - the first large allocation size to require two blocks -
          also had 50% internal fragmentation. This is because we required large allocations to be
          blockSize aligned, so that MarkedBlock::blockFor() would work. I decided to rewrite all of
          that. Cells no longer have to be owned by a MarkedBlock. They can now alternatively be
          owned by a LargeAllocation. These two things are abstracted as CellContainer. You know that
          a cell is owned by a LargeAllocation if the MarkedBlock::atomSize / 2 bit is set.
          Basically, large allocations are deliberately misaligned by 8 bytes. This actually works
          out great since (1) typed arrays won't use large allocations anyway since they have their
          own malloc fallback and (2) large array butterflies already have a 8 byte header, which
          means that the 8 byte base misalignment aligns the large array payload on a 16 byte
          boundary. I took extreme care to make sure that the isLargeAllocation bit checks are as
          rare as possible; for example, ExecState::vm() skips the check because we know that callees
          must be small allocations. It's also possible to use template tricks to do one check for
          cell container kind, and then invoke a function specialized for MarkedBlock or a function
          specialized for LargeAllocation. LargeAllocation includes stubs for all MarkedBlock methods
          that get used from functions that are template-specialized like this. That's mostly to
          speed up the GC marking code. Most other code can use CellContainer API or HeapCell API
          directly. That's another thing: HeapCell, the common base of JSCell and auxiliary
          allocations, is now smart enough to do a lot of things for you, like HeapCell::vm(),
          HeapCell::heap(), HeapCell::isLargeAllocation(), and HeapCell::cellContainer(). The size
          cutoff for large allocations is runtime-configurable, so long as you don't choose something
          so small that callees end up large. I found that 400 bytes is roughly optimal. This means
          that the MarkedBlock size classes end up being:
          
          16, 32, 48, 64, 80, 112, 160, 224, 320
          
          The next size class would have been 432, but that's above the 400 byte cutoff. All of this
          is configurable with --sizeClassProgression and --largeAllocationCutoff. You can see what
          size classes you end up with by doing --dumpSizeClasses=true.
        
        - Copied space uses 64KB blocks, while marked space used to use 16KB blocks. Allocating a lot
          of stuff in 16KB blocks was slower than allocating it in 64KB blocks because the GC had a
          lot of per-block overhead. I removed this overhead: It's now 2x faster to scan all
          MarkedBlocks because the list that contains the interesting meta-data is allocated on the
          side, for better locality during a sequential walk. It's no longer necessary to scan
          MarkedBlocks to find WeakSets, since the sets of WeakSets for eden scan and full scan are
          maintained on-the-fly. It's no longer necessary to scan all MarkedBlocks to clear mark
          bits because we now use versioned mark bits: to clear then, just increment the 64-bit
          heap version. It's no longer necessary to scan retired MarkedBlocks while allocating
          because marking retires them on-the-fly. It's no longer necessary to sort all blocks in
          the IncrementalSweeper's snapshot because blocks now know if they are in the snapshot. Put
          together, these optimizations allowed me to reduce block size to 16KB without losing much
          performance. There is some small perf loss on JetStream/splay, but not enough to hurt
          JetStream overall. I tried reducing block sizes further, to 4KB, since that is a
          progression on membuster. That's not possible yet, since there is still enough per-block
          overhead yet that such a reduction hurts JetStream too much. I filed a bug about improving
          this further: https://bugs.webkit.org/show_bug.cgi?id=161581.
        
        - Even after all of that, copying butterflies was still faster because it allowed us to skip
          sweeping dead space. A good GC allocates over dead bytes without explicitly freeing them,
          so the GC pause is O(size of live), not O(size of live + dead). O(dead) is usually much
          larger than O(live), especially in an eden collection. Copying satisfies this premise while
          mark+sweep does not. So, I invented a new kind of allocator: bump'n'pop. Previously, our
          MarkedSpace allocator was a freelist pop. That's simple and easy to inline but requires
          that we walk the block to build a free list. This means walking dead space. The new
          allocator allows totally free MarkedBlocks to simply set up a bump-pointer arena instead.
          The allocator is a hybrid of bump-pointer and freelist pop. It tries bump first. The bump
          pointer always bumps by cellSize, so the result of filling a block with bumping looks as if
          we had used freelist popping to fill it. Additionally, each MarkedBlock now has a bit to
          quickly tell if the block is entirely free. This makes sweeping O(1) whenever a MarkedBlock
          is completely empty, which is the common case because of the generational hypothesis: the
          number of objects that survive an eden collection is a tiny fraction of the number of
          objects that had been allocated, and this fraction is so small that there are typically
          fewer than one survivors per MarkedBlock. This change was enough to make this change a net
          win over tip-of-tree.
        
        - FTL now shares the same allocation fast paths as everything else, which is great, because
          bump'n'pop has gnarly control flow. We don't really want B3 to have to think about that
          control flow, since it won't be able to improve the machine code we write ourselves. GC
          fast paths are best written in assembly. So, I've empowered B3 to have even better support
          for Patchpoint terminals. It's now totally fine for a Patchpoint terminal to be non-Void.
          So, the new FTL allocation fast paths are just Patchpoint terminals that call through to
          AssemblyHelpers::emitAllocate(). B3 still reasons about things like constant-folding the
          size class calculation and constant-hoisting the allocator. Also, I gave the FTL the
          ability to constant-fold some allocator logic (in case we first assume that we're doing a
          variable-length allocation but then realize that the length is known). I think it makes
          sense to have constant folding rules in FTL::Output, or whatever the B3 IR builder is,
          since this makes lowering easier (you can constant fold during lowering more easily) and it
          reduces the amount of malloc traffic. In the future, we could teach B3 how to better
          constant-fold this code. That would require allowing loads to be constant-folded, which is
          doable but hella tricky.
        
        - It used to be that if a logical object allocation required two physical allocations (first
          the butterfly and then the cell), then the JIT would emit the code in such a way that a
          failure in the second fast path would cause us to forget the successful first physical
          allocation. This was pointlessly wasteful. It turns out that it's very cheap to devote a
          register to storing either the butterfly or null, because the butterfly register is anyway
          going to be free inside the first allocation. The only overhead here is zeroing the
          butterfly register. With that in place, we can just pass the butterfly-or-null to the slow
          path, which can then either allocate a butterfly or not. So now we never waste a successful
          allocation. This patch implements such a solution both in DFG (where it's easy to do this
          since we control registers already) and in FTL (where it's annoying, because mutable
          "butterfly-or-null" variables are hard to say in SSA; also I realized that we had code
          duplicated the JSArray allocation utility, so I deduplicated it). This came up because in
          one version of this patch, this wastage would resonate with some Kraken benchmark: the
          benchmark would always allocate N small things followed by one bigger thing. The problem
          was I accidentally adjusted the various fixed overheads in MarkedBlock in such a way that
          the JSObject size class, which both the small and big thing shared for their cell, could
          hold exactly N cells per MarkedBlock. Then the benchmark would always call slow path when
          it allocated the big thing. So, it would end up having to allocate the big thing's large
          butterfly twice, every single time! Ouch!
        
        - It used to be that we zeroed CopiedBlocks using memset, and so array allocations enjoyed
          amortization of the cost of zeroing. This doesn't work anymore - it's now up to the client
          of the allocator to initialize the object to whatever state they need. It used to be that
          we would just use a dumb loop. I initially changed this so that we would end up in memset
          for large allocations, but this didn't actually help performance that much. I got a much
          better result by playing with different memsets written in assembly. First I wrote one
          using non-temporal stores. That was a small speed-up over memset. Then I tried the classic
          "rep stos" approach, and holy cow that version was fast. It's a ~20% speed-up on array
          allocation microbenchmarks. So, this patch adds code paths to do "rep stos" on x86_64, or
          memset, or use a loop, as appropriate, for both "contiguous" arrays (holes are zero) and
          double arrays (holes are PNaN). Note that the JIT always emits either a loop or a flat slab
          of stores (if the size is known), but those paths in the JIT won't trigger for
          NewArrayWithSize() if the size is large, since that takes us to the
          operationNewArrayWithSize() slow path, which calls into JSArray::create(). That's why the
          optimizations here are all in JSArray::create() - that's the hot place for large arrays
          that need to be filled with holes.
        
        All of this put together gives us neutral perf on JetStream,  membuster, and PLT3, a ~1%
        regression on Speedometer, and up to a 4% regression Kraken. The Kraken regression is
        because Kraken was allocating exactly 1024 element arrays at a rate of 400MB/sec. This is a
        best-case scenario for bump allocation. I think that we should fix bmalloc to make up the
        difference, but take the hit for now because it's a crazy corner case. By comparison, the
        alternative approach of using a copy barrier would have cost us 1-2%. That's the real
        apples-to-apples comparison if your premise is that we should have a concurrent GC. After we
        finish removing copied space, we will be barrier-ready for concurrent GC: we already have a
        marking barrier and we simply won't need a copying barrier. This change gets us there for
        the purposes of our benchmarks, since the remaining clients of copied space are not very
        important. On the other hand, if we keep copying, then getting barrier-ready would mean
        adding back the copy barrier, which costs more perf.
        
        We might get bigger speed-ups once we remove CopiedSpace altogether. That requires moving
        typed arrays and a few other weird things over to Aux MarkedSpace.
        
        This also includes some header sanitization. The introduction of AuxiliaryBarrier, HeapCell,
        and CellContainer meant that I had to include those files from everywhere. Fortunately,
        just including JSCInlines.h (instead of manually including the files that includes) is
        usually enough. So, I made most of JSC's cpp files include JSCInlines.h, which is something
        that we were already basically doing. In places where JSCInlines.h would be too much, I just
        included HeapInlines.h. This got weird, because we previously included HeapInlines.h from
        JSObject.h. That's bad because it led to some circular dependencies, so I fixed it - but that
        meant having to manually include HeapInlines.h from the places that previously got it
        implicitly via JSObject.h. But that led to more problems for some reason: I started getting
        build errors because non-JSC files were having trouble including Opcode.h. That's just silly,
        since Opcode.h is meant to be an internal JSC header. So, I made it an internal header and
        made it impossible to include it from outside JSC. This was a lot of work, but it was
        necessary to get the patch to build on all ports. It's also a net win. There were many places
        in WebCore that were transitively including a *ton* of JSC headers just because of the
        JSObject.h->HeapInlines.h edge and a bunch of dependency edges that arose from some public
        (for WebCore) JSC headers needing Interpreter.h or Opcode.h for bad reasons.

        * API/JSManagedValue.mm:
        (-[JSManagedValue initWithValue:]):
        * API/JSTypedArray.cpp:
        * API/ObjCCallbackFunction.mm:
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        (testWeakValue): Deleted.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::link):
        (JSC::AbstractMacroAssembler::JumpList::linkTo):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        * assembler/MacroAssemblerCodeRef.cpp: Added.
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
        (JSC::MacroAssemblerCodePtr::dumpWithName):
        (JSC::MacroAssemblerCodePtr::dump):
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
        (JSC::MacroAssemblerCodeRef::dump):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr): Deleted.
        (JSC::MacroAssemblerCodePtr::dumpWithName): Deleted.
        (JSC::MacroAssemblerCodePtr::dump): Deleted.
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef): Deleted.
        (JSC::MacroAssemblerCodeRef::dump): Deleted.
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendBoolConstant):
        * b3/B3BasicBlock.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3StackmapGenerationParams.h:
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointTerminalReturnValue):
        (JSC::B3::run):
        * bindings/ScriptValue.cpp:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        * bytecode/BytecodeBasicBlock.cpp:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor): Deleted.
        * bytecode/CallLinkStatus.cpp:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::clearLLIntGetByIdCache):
        (JSC::CodeBlock::predictedMachineCodeSize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitCodeMap): Deleted.
        (JSC::clearLLIntGetByIdCache): Deleted.
        * bytecode/ExecutionCounter.h:
        * bytecode/Instruction.h:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::isNull):
        (JSC::ObjectAllocationProfile::initialize):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/PreciseJumpTargets.cpp:
        * bytecode/StructureStubInfo.cpp:
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::vm): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedInstructionStream.cpp:
        * bytecode/UnlinkedInstructionStream.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCompile.cpp:
        * ftl/FTLJITFinalizer.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::allocateArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize): Deleted.
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::appendSuccessor):
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLOutput.h:
        * ftl/FTLValueFromBlock.h:
        (JSC::FTL::ValueFromBlock::operator bool):
        (JSC::FTL::ValueFromBlock::ValueFromBlock): Deleted.
        * ftl/FTLWeightedTarget.h:
        (JSC::FTL::WeightedTarget::frequentedBlock):
        * heap/CellContainer.h: Added.
        (JSC::CellContainer::CellContainer):
        (JSC::CellContainer::operator bool):
        (JSC::CellContainer::isMarkedBlock):
        (JSC::CellContainer::isLargeAllocation):
        (JSC::CellContainer::markedBlock):
        (JSC::CellContainer::largeAllocation):
        * heap/CellContainerInlines.h: Added.
        (JSC::CellContainer::isMarked):
        (JSC::CellContainer::isMarkedOrNewlyAllocated):
        (JSC::CellContainer::noteMarked):
        (JSC::CellContainer::cellSize):
        (JSC::CellContainer::weakSet):
        (JSC::CellContainer::flipIfNecessary):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::~ConservativeRoots):
        (JSC::ConservativeRoots::grow):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/ConservativeRoots.h:
        (JSC::ConservativeRoots::roots):
        * heap/CopyToken.h:
        * heap/FreeList.cpp: Added.
        (JSC::FreeList::dump):
        * heap/FreeList.h: Added.
        (JSC::FreeList::FreeList):
        (JSC::FreeList::list):
        (JSC::FreeList::bump):
        (JSC::FreeList::operator==):
        (JSC::FreeList::operator!=):
        (JSC::FreeList::operator bool):
        (JSC::FreeList::allocationWillFail):
        (JSC::FreeList::allocationWillSucceed):
        * heap/GCTypeMap.h: Added.
        (JSC::GCTypeMap::operator[]):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::gatherScratchBufferRoots):
        (JSC::Heap::clearLivenessData):
        (JSC::Heap::visitSmallStrings):
        (JSC::Heap::visitConservativeRoots):
        (JSC::Heap::removeDeadCompilerWorklistEntries):
        (JSC::Heap::gatherExtraHeapSnapshotData):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::visitProtectedObjects):
        (JSC::Heap::visitArgumentBuffers):
        (JSC::Heap::visitException):
        (JSC::Heap::visitStrongHandles):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::converge):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::clearUnmarkedExecutables):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collect):
        (JSC::Heap::collectWithoutAnySweep):
        (JSC::Heap::collectImpl):
        (JSC::Heap::suspendCompilerThreads):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::flushOldStructureIDTables):
        (JSC::Heap::flushWriteBarrierBuffer):
        (JSC::Heap::stopAllocation):
        (JSC::Heap::prepareForMarking):
        (JSC::Heap::reapWeakHandles):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::sweepArrayBuffers):
        (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
        (JSC::MarkedBlockSnapshotFunctor::operator()):
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::deleteSourceProviderCaches):
        (JSC::Heap::notifyIncrementalSweeper):
        (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::Heap::resetAllocators):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Zombify::visit):
        (JSC::Heap::forEachCodeBlockImpl):
        * heap/Heap.h:
        (JSC::Heap::allocatorForObjectWithoutDestructor):
        (JSC::Heap::allocatorForObjectWithDestructor):
        (JSC::Heap::allocatorForAuxiliaryData):
        (JSC::Heap::jitStubRoutines):
        (JSC::Heap::codeBlockSet):
        (JSC::Heap::storageAllocator): Deleted.
        * heap/HeapCell.h:
        (JSC::HeapCell::isZapped): Deleted.
        * heap/HeapCellInlines.h: Added.
        (JSC::HeapCell::isLargeAllocation):
        (JSC::HeapCell::cellContainer):
        (JSC::HeapCell::markedBlock):
        (JSC::HeapCell::largeAllocation):
        (JSC::HeapCell::heap):
        (JSC::HeapCell::vm):
        (JSC::HeapCell::cellSize):
        (JSC::HeapCell::allocatorAttributes):
        (JSC::HeapCell::destructionMode):
        (JSC::HeapCell::cellKind):
        * heap/HeapInlines.h:
        (JSC::Heap::heap):
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::testAndSetMarked):
        (JSC::Heap::setMarked):
        (JSC::Heap::cellSize):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        (JSC::Heap::allocateAuxiliary):
        (JSC::Heap::tryAllocateAuxiliary):
        (JSC::Heap::tryReallocateAuxiliary):
        (JSC::Heap::isPointerGCObject): Deleted.
        (JSC::Heap::isValueGCObject): Deleted.
        * heap/HeapOperation.cpp: Added.
        (WTF::printInternal):
        * heap/HeapOperation.h:
        * heap/HeapUtil.h: Added.
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        (JSC::HeapUtil::isPointerGCObjectJSCell):
        (JSC::HeapUtil::isValueGCObject):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::sweepNextBlock):
        * heap/IncrementalSweeper.h:
        * heap/LargeAllocation.cpp: Added.
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::LargeAllocation):
        (JSC::LargeAllocation::lastChanceToFinalize):
        (JSC::LargeAllocation::shrink):
        (JSC::LargeAllocation::visitWeakSet):
        (JSC::LargeAllocation::reapWeakSet):
        (JSC::LargeAllocation::flip):
        (JSC::LargeAllocation::isEmpty):
        (JSC::LargeAllocation::sweep):
        (JSC::LargeAllocation::destroy):
        (JSC::LargeAllocation::dump):
        * heap/LargeAllocation.h: Added.
        (JSC::LargeAllocation::fromCell):
        (JSC::LargeAllocation::cell):
        (JSC::LargeAllocation::isLargeAllocation):
        (JSC::LargeAllocation::heap):
        (JSC::LargeAllocation::vm):
        (JSC::LargeAllocation::weakSet):
        (JSC::LargeAllocation::clearNewlyAllocated):
        (JSC::LargeAllocation::isNewlyAllocated):
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
        (JSC::LargeAllocation::isLive):
        (JSC::LargeAllocation::hasValidCell):
        (JSC::LargeAllocation::cellSize):
        (JSC::LargeAllocation::aboveLowerBound):
        (JSC::LargeAllocation::belowUpperBound):
        (JSC::LargeAllocation::contains):
        (JSC::LargeAllocation::attributes):
        (JSC::LargeAllocation::flipIfNecessary):
        (JSC::LargeAllocation::flipIfNecessaryConcurrently):
        (JSC::LargeAllocation::testAndSetMarked):
        (JSC::LargeAllocation::setMarked):
        (JSC::LargeAllocation::clearMarked):
        (JSC::LargeAllocation::noteMarked):
        (JSC::LargeAllocation::headerSize):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::isPagedOut):
        (JSC::MarkedAllocator::retire):
        (JSC::MarkedAllocator::filterNextBlock):
        (JSC::MarkedAllocator::setNextBlockToSweep):
        (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::allocateSlowCase):
        (JSC::MarkedAllocator::tryAllocateSlowCase):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::blockHeaderSize):
        (JSC::MarkedAllocator::blockSizeForBytes):
        (JSC::MarkedAllocator::tryAllocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::MarkedAllocator::setFreeList):
        (JSC::isListPagedOut): Deleted.
        (JSC::MarkedAllocator::tryAllocateHelper): Deleted.
        (JSC::MarkedAllocator::tryPopFreeList): Deleted.
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        (JSC::MarkedAllocator::allocateBlock): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::offsetOfFreeList):
        (JSC::MarkedAllocator::offsetOfCellSize):
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::forEachBlock):
        (JSC::MarkedAllocator::offsetOfFreeListHead): Deleted.
        (JSC::MarkedAllocator::MarkedAllocator): Deleted.
        (JSC::MarkedAllocator::init): Deleted.
        (JSC::MarkedAllocator::stopAllocating): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::Handle):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode):
        (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::lastChanceToFinalize):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::Handle::zap):
        (JSC::MarkedBlock::Handle::forEachFreeCell):
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::Handle::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessarySlow):
        (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::assertFlipped):
        (JSC::MarkedBlock::needsFlip):
        (JSC::MarkedBlock::Handle::needsFlip):
        (JSC::MarkedBlock::Handle::willRemoveBlock):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::markCount):
        (JSC::MarkedBlock::Handle::isEmpty):
        (JSC::MarkedBlock::clearHasAnyMarked):
        (JSC::MarkedBlock::noteMarkedSlow):
        (WTF::printInternal):
        (JSC::MarkedBlock::create): Deleted.
        (JSC::MarkedBlock::destroy): Deleted.
        (JSC::MarkedBlock::callDestructor): Deleted.
        (JSC::MarkedBlock::specializedSweep): Deleted.
        (JSC::MarkedBlock::sweep): Deleted.
        (JSC::MarkedBlock::sweepHelper): Deleted.
        (JSC::MarkedBlock::stopAllocating): Deleted.
        (JSC::MarkedBlock::clearMarksWithCollectionType): Deleted.
        (JSC::MarkedBlock::lastChanceToFinalize): Deleted.
        (JSC::MarkedBlock::resumeAllocating): Deleted.
        (JSC::MarkedBlock::didRetireBlock): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::VoidFunctor::returnValue):
        (JSC::MarkedBlock::CountFunctor::CountFunctor):
        (JSC::MarkedBlock::CountFunctor::count):
        (JSC::MarkedBlock::CountFunctor::returnValue):
        (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
        (JSC::MarkedBlock::Handle::isOnBlocksToSweep):
        (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep):
        (JSC::MarkedBlock::Handle::state):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::handle):
        (JSC::MarkedBlock::Handle::block):
        (JSC::MarkedBlock::firstAtom):
        (JSC::MarkedBlock::atoms):
        (JSC::MarkedBlock::isAtomAligned):
        (JSC::MarkedBlock::Handle::cellAlign):
        (JSC::MarkedBlock::blockFor):
        (JSC::MarkedBlock::Handle::allocator):
        (JSC::MarkedBlock::Handle::heap):
        (JSC::MarkedBlock::Handle::vm):
        (JSC::MarkedBlock::vm):
        (JSC::MarkedBlock::Handle::weakSet):
        (JSC::MarkedBlock::weakSet):
        (JSC::MarkedBlock::Handle::shrink):
        (JSC::MarkedBlock::Handle::visitWeakSet):
        (JSC::MarkedBlock::Handle::reapWeakSet):
        (JSC::MarkedBlock::Handle::cellSize):
        (JSC::MarkedBlock::cellSize):
        (JSC::MarkedBlock::Handle::attributes):
        (JSC::MarkedBlock::attributes):
        (JSC::MarkedBlock::Handle::needsDestruction):
        (JSC::MarkedBlock::Handle::destruction):
        (JSC::MarkedBlock::Handle::cellKind):
        (JSC::MarkedBlock::Handle::markCount):
        (JSC::MarkedBlock::Handle::size):
        (JSC::MarkedBlock::atomNumber):
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessaryConcurrently):
        (JSC::MarkedBlock::Handle::flipIfNecessary):
        (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
        (JSC::MarkedBlock::Handle::flipForEdenCollection):
        (JSC::MarkedBlock::assertFlipped):
        (JSC::MarkedBlock::Handle::assertFlipped):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::testAndSetMarked):
        (JSC::MarkedBlock::Handle::isNewlyAllocated):
        (JSC::MarkedBlock::Handle::setNewlyAllocated):
        (JSC::MarkedBlock::Handle::clearNewlyAllocated):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::Handle::forEachCell):
        (JSC::MarkedBlock::Handle::forEachLiveCell):
        (JSC::MarkedBlock::Handle::forEachDeadCell):
        (JSC::MarkedBlock::Handle::needsSweeping):
        (JSC::MarkedBlock::Handle::isAllocated):
        (JSC::MarkedBlock::Handle::isMarked):
        (JSC::MarkedBlock::Handle::isFreeListed):
        (JSC::MarkedBlock::hasAnyMarked):
        (JSC::MarkedBlock::noteMarked):
        (WTF::MarkedBlockHash::hash):
        (JSC::MarkedBlock::FreeList::FreeList): Deleted.
        (JSC::MarkedBlock::allocator): Deleted.
        (JSC::MarkedBlock::heap): Deleted.
        (JSC::MarkedBlock::shrink): Deleted.
        (JSC::MarkedBlock::visitWeakSet): Deleted.
        (JSC::MarkedBlock::reapWeakSet): Deleted.
        (JSC::MarkedBlock::willRemoveBlock): Deleted.
        (JSC::MarkedBlock::didConsumeFreeList): Deleted.
        (JSC::MarkedBlock::markCount): Deleted.
        (JSC::MarkedBlock::isEmpty): Deleted.
        (JSC::MarkedBlock::destruction): Deleted.
        (JSC::MarkedBlock::cellKind): Deleted.
        (JSC::MarkedBlock::size): Deleted.
        (JSC::MarkedBlock::capacity): Deleted.
        (JSC::MarkedBlock::setMarked): Deleted.
        (JSC::MarkedBlock::clearMarked): Deleted.
        (JSC::MarkedBlock::isNewlyAllocated): Deleted.
        (JSC::MarkedBlock::setNewlyAllocated): Deleted.
        (JSC::MarkedBlock::clearNewlyAllocated): Deleted.
        (JSC::MarkedBlock::isLive): Deleted.
        (JSC::MarkedBlock::isLiveCell): Deleted.
        (JSC::MarkedBlock::forEachCell): Deleted.
        (JSC::MarkedBlock::forEachLiveCell): Deleted.
        (JSC::MarkedBlock::forEachDeadCell): Deleted.
        (JSC::MarkedBlock::needsSweeping): Deleted.
        (JSC::MarkedBlock::isAllocated): Deleted.
        (JSC::MarkedBlock::isMarkedOrRetired): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::initializeSizeClassForStepSize):
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::allocate):
        (JSC::MarkedSpace::tryAllocate):
        (JSC::MarkedSpace::allocateLarge):
        (JSC::MarkedSpace::tryAllocateLarge):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::sweepLargeAllocations):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::prepareForMarking):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::freeOrShrinkBlock):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::VerifyMarked::operator()):
        (JSC::MarkedSpace::flip):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::addActiveWeakSet):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::didAllocateInBlock):
        (JSC::MarkedSpace::forEachAllocator): Deleted.
        (JSC::VerifyMarkedOrRetired::operator()): Deleted.
        (JSC::MarkedSpace::clearMarks): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sizeClassToIndex):
        (JSC::MarkedSpace::indexToSizeClass):
        (JSC::MarkedSpace::version):
        (JSC::MarkedSpace::blocksWithNewObjects):
        (JSC::MarkedSpace::largeAllocations):
        (JSC::MarkedSpace::largeAllocationsNurseryOffset):
        (JSC::MarkedSpace::largeAllocationsOffsetForThisCollection):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionBegin):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionEnd):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionSize):
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::tryAllocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::optimalSizeFor):
        (JSC::MarkedSpace::didAddBlock): Deleted.
        (JSC::MarkedSpace::didAllocateInBlock): Deleted.
        (JSC::MarkedSpace::objectCount): Deleted.
        (JSC::MarkedSpace::size): Deleted.
        (JSC::MarkedSpace::capacity): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        (JSC::SlotVisitor::noteLiveAuxiliaryCell):
        (JSC::SlotVisitor::visitChildren):
        * heap/SlotVisitor.h:
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock):
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectContainer):
        (JSC::WeakBlock::disconnectMarkedBlock): Deleted.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::shrink):
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::container):
        (JSC::WeakSet::setContainer):
        (JSC::WeakSet::WeakSet):
        (JSC::WeakSet::visit):
        (JSC::WeakSet::shrink): Deleted.
        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate):
        * inspector/InjectedScriptManager.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/ScriptDebugServer.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        (JSC::StackFrame::sourceID): Deleted.
        (JSC::StackFrame::sourceURL): Deleted.
        (JSC::StackFrame::functionName): Deleted.
        (JSC::StackFrame::computeLineAndColumn): Deleted.
        (JSC::StackFrame::toString): Deleted.
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        * jit/JIT.cpp:
        (JSC::JIT::compileCTINativeCall):
        (JSC::JIT::link):
        * jit/JIT.h:
        (JSC::JIT::compileCTINativeCall): Deleted.
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * jit/JITThunks.cpp:
        * jit/JITThunks.h:
        * jsc.cpp:
        (functionDescribeArray):
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntExceptions.cpp:
        * llint/LLIntThunks.cpp:
        * llint/LLIntThunks.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ModuleAnalyzer.cpp:
        * parser/NodeConstructors.h:
        * parser/Nodes.h:
        * profiler/ProfilerBytecode.cpp:
        * profiler/ProfilerBytecode.h:
        * profiler/ProfilerBytecodeSequence.cpp:
        * runtime/ArrayConventions.h:
        (JSC::indexingHeaderForArrayStorage):
        (JSC::baseIndexingHeaderForArrayStorage):
        (JSC::indexingHeaderForArray): Deleted.
        (JSC::baseIndexingHeaderForArray): Deleted.
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::vectorLength):
        (JSC::ArrayStorage::totalSizeFor):
        (JSC::ArrayStorage::totalSize):
        (JSC::ArrayStorage::availableVectorLength):
        (JSC::ArrayStorage::optimalVectorLength):
        (JSC::ArrayStorage::sizeFor): Deleted.
        * runtime/AuxiliaryBarrier.h: Added.
        (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier::clear):
        (JSC::AuxiliaryBarrier::get):
        (JSC::AuxiliaryBarrier::slot):
        (JSC::AuxiliaryBarrier::operator bool):
        (JSC::AuxiliaryBarrier::setWithoutBarrier):
        * runtime/AuxiliaryBarrierInlines.h: Added.
        (JSC::AuxiliaryBarrier<T>::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier<T>::set):
        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::availableContiguousVectorLength):
        (JSC::Butterfly::optimalContiguousVectorLength):
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::growArrayRight):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/CommonSlowPathsExceptions.cpp:
        * runtime/CommonSlowPathsExceptions.h:
        * runtime/DataView.cpp:
        * runtime/DirectArguments.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        * runtime/Error.cpp:
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorInstance.h:
        * runtime/Exception.cpp:
        * runtime/Exception.h:
        * runtime/GeneratorFrame.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::InternalFunction):
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/IntlObject.cpp:
        * runtime/IteratorPrototype.cpp:
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::JSArray::setLengthWritable):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly):
        (JSC::createArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/JSArrayBufferView.h:
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::JSCallee):
        * runtime/JSCell.cpp:
        (JSC::JSCell::estimatedSize):
        * runtime/JSCell.h:
        (JSC::JSCell::cellStateOffset): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor):
        (JSC::JSCell::vm): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::setFunctionName):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::JSFunction):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSJob.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::createInitialArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::copyButterfly): Deleted.
        (JSC::JSObject::copyBackingStore): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::globalObject):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): Deleted.
        * runtime/JSObjectInlines.h:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        * runtime/JSScope.h:
        (JSC::JSScope::globalObject):
        (JSC::JSScope::vm): Deleted.
        * runtime/JSSetIterator.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrayViewPrototype.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapIteratorPrototype.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/Operations.h:
        (JSC::scribbleFreeCells):
        (JSC::scribble):
        * runtime/Options.h:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/RegExp.cpp:
        (JSC::RegExp::match):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/RegExp.h:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpPrototype.cpp:
        (JSC::genericSplit):
        * runtime/RuntimeType.cpp:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SetConstructor.cpp:
        * runtime/SetIteratorPrototype.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/StackFrame.cpp: Added.
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * runtime/StackFrame.h: Added.
        (JSC::StackFrame::isNative):
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:
        * runtime/StructureInlines.h:
        (JSC::Structure::propertyTable):
        * runtime/TemplateRegistry.cpp:
        * runtime/TestRunnerUtils.cpp:
        (JSC::finalizeStatsAtEndOfTesting):
        * runtime/TestRunnerUtils.h:
        * runtime/TypeProfilerLog.cpp:
        * runtime/TypeSet.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::ensureStackCapacityForCLoop):
        (JSC::VM::isSafeToRecurseSoftCLoop):
        * runtime/VM.h:
        * runtime/VMEntryScope.h:
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * testRegExp.cpp:
        (testOneRegExp):
        * tools/JSDollarVM.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInObjectSpace):

2018-07-18  Babak Shafiei  <bshafiei@apple.com>

        Cherry-pick r233893. rdar://problem/42345044

    CodeBlock::baselineVersion() should account for executables with purged codeBlocks.
    https://bugs.webkit.org/show_bug.cgi?id=187736
    <rdar://problem/42114371>
    
    Reviewed by Michael Saboff.
    
    CodeBlock::baselineVersion() currently checks for a null replacement but does not
    account for the fact that that the replacement can also be null due to the
    executable having being purged of its codeBlocks due to a memory event (see
    ExecutableBase::clearCode()).  This patch adds code to account for this.
    
    * bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::baselineVersion):
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@233893 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-07-17  Mark Lam  <mark.lam@apple.com>

            CodeBlock::baselineVersion() should account for executables with purged codeBlocks.
            https://bugs.webkit.org/show_bug.cgi?id=187736
            <rdar://problem/42114371>

            Reviewed by Michael Saboff.

            CodeBlock::baselineVersion() currently checks for a null replacement but does not
            account for the fact that that the replacement can also be null due to the
            executable having being purged of its codeBlocks due to a memory event (see
            ExecutableBase::clearCode()).  This patch adds code to account for this.

            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::baselineVersion):
            
2018-04-24  Keith Miller  <keith_miller@apple.com>

        fromCharCode is missing some exception checks
        https://bugs.webkit.org/show_bug.cgi?id=184952

        Reviewed by Saam Barati.

        * stress/fromCharCode-exception-check.js: Added.
        (get catch):

2018-03-28  Robin Morisset  <rmorisset@apple.com>

        appendQuotedJSONString stops on arithmetic overflow instead of propagating it upwards
        https://bugs.webkit.org/show_bug.cgi?id=183894

        Reviewed by Saam Barati.

        Use the return value of appendQuotedJSONString to fail more gracefully when given a string that is too large to handle.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2018-05-08  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230740. rdar://problem/40050731

    A put is not an ExistingProperty put when we transition a structure because of an attributes change
    https://bugs.webkit.org/show_bug.cgi?id=184706
    <rdar://problem/38871451>
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * stress/put-by-id-direct-strict-transition.js: Added.
    (const.foo):
    (j.const.obj.set hello):
    * stress/put-by-id-direct-transition.js: Added.
    (const.foo):
    (j.const.obj.set hello):
    * stress/put-getter-setter-by-id-strict-transition.js: Added.
    (const.foo):
    (j.const.obj.set hello):
    * stress/put-getter-setter-by-id-transition.js: Added.
    (const.foo):
    (j.const.obj.set hello):
    
    Source/JavaScriptCore:
    
    When putting a property on a structure and the slot is a different
    type, the slot can't be said to have already been existing.
    
    * runtime/JSObjectInlines.h:
    (JSC::JSObject::putDirectInternal):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230740 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-17  JF Bastien  <jfbastien@apple.com>

            A put is not an ExistingProperty put when we transition a structure because of an attributes change
            https://bugs.webkit.org/show_bug.cgi?id=184706
            <rdar://problem/38871451>

            Reviewed by Saam Barati.

            When putting a property on a structure and the slot is a different
            type, the slot can't be said to have already been existing.

            * runtime/JSObjectInlines.h:
            (JSC::JSObject::putDirectInternal):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230101. rdar://problem/39155394

    Out-of-bounds accesses due to a missing check for MAX_STORAGE_VECTOR_LENGTH in unshiftCountForAnyIndexingType
    https://bugs.webkit.org/show_bug.cgi?id=183657
    JSTests:
    
    Reviewed by Keith Miller.
    
    * stress/large-unshift-splice.js: Added.
    (make_contig_arr):
    
    Source/JavaScriptCore:
    
    <rdar://problem/38464399>
    
    Reviewed by Keith Miller.
    
    There was just a missing check in unshiftCountForIndexingType.
    I've also replaced 'return false' by 'return true' in the case of an 'out-of-memory' exception, because 'return false' means 'please continue to the slow path',
    and the slow path has an assert that there is no unhandled exception (line 360 of ArrayPrototype.cpp).
    Finally, I made the assert in ensureLength a release assert as it would have caught this bug and prevented it from being a security risk.
    
    * runtime/ArrayPrototype.cpp:
    (JSC::unshift):
    * runtime/JSArray.cpp:
    (JSC::JSArray::unshiftCountWithAnyIndexingType):
    * runtime/JSObject.h:
    (JSC::JSObject::ensureLength):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230101 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-30  Robin Morisset  <rmorisset@apple.com>

            Out-of-bounds accesses due to a missing check for MAX_STORAGE_VECTOR_LENGTH in unshiftCountForAnyIndexingType
            https://bugs.webkit.org/show_bug.cgi?id=183657
            <rdar://problem/38464399>

            Reviewed by Keith Miller.

            There was just a missing check in unshiftCountForIndexingType.
            I've also replaced 'return false' by 'return true' in the case of an 'out-of-memory' exception, because 'return false' means 'please continue to the slow path',
            and the slow path has an assert that there is no unhandled exception (line 360 of ArrayPrototype.cpp).
            Finally, I made the assert in ensureLength a release assert as it would have caught this bug and prevented it from being a security risk.

            * runtime/ArrayPrototype.cpp:
            (JSC::unshift):
            * runtime/JSArray.cpp:
            (JSC::JSArray::unshiftCountWithAnyIndexingType):
            * runtime/JSObject.h:
            (JSC::JSObject::ensureLength):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229850. rdar://problem/39155286

    Race Condition in arrayProtoFuncReverse() causes wrong results or crash
    https://bugs.webkit.org/show_bug.cgi?id=183901

    Reviewed by Keith Miller.

    JSTests:

    New test.

    * stress/array-reverse-doesnt-clobber.js: Added.
    (testArrayReverse):
    (createArrayOfArrays):
    (createArrayStorage):

    Source/JavaScriptCore:

    Added write barriers to ensure the reversed contents are properly marked.

    * runtime/ArrayPrototype.cpp:
    (JSC::arrayProtoFuncReverse):


    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229850 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-22  Michael Saboff  <msaboff@apple.com>

            Race Condition in arrayProtoFuncReverse() causes wrong results or crash
            https://bugs.webkit.org/show_bug.cgi?id=183901

            Reviewed by Keith Miller.

            Added write barriers to ensure the reversed contents are properly marked.

            * runtime/ArrayPrototype.cpp:
            (JSC::arrayProtoFuncReverse):

2017-10-26  Mark Lam  <mark.lam@apple.com>

        JSRopeString::RopeBuilder::append() should check for overflows.
        https://bugs.webkit.org/show_bug.cgi?id=178385
        <rdar://problem/35027468>

        Reviewed by Saam Barati.

        1. Made RopeString check for overflow like the Checked class does.
        2. Added a missing overflow check in objectProtoFuncToString().

        * runtime/JSString.cpp:
        (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
        (JSC::JSRopeString::RopeBuilder::expand): Deleted.
        * runtime/JSString.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Operations.h:
        (JSC::jsStringFromRegisterArray):
        (JSC::jsStringFromArguments):

2018-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        DFG strength reduction fails to convert NumberToStringWithValidRadixConstant for 0 to constant '0'
        https://bugs.webkit.org/show_bug.cgi?id=182213

        Reviewed by Mark Lam.

        toStringWithRadixInternal is originally used for the slow path if the given value is larger than radix or negative.
        As a result, it does not accept 0 correctly, and produces an empty string. Since DFGStrengthReductionPhase uses
        this function, it accidentally converts NumberToStringWithValidRadixConstant(0, radix) to an empty string.
        This patch fixes toStringWithRadixInternal to accept 0. This change fixes twitch.tv's issue.

        We also add a careful cast to avoid `-INT32_MIN`. It does not produce incorrect value in x86 in practice,
        but it is UB, and a compiler may assume that the given value is never INT32_MIN and could do an incorrect optimization.

        * runtime/NumberPrototype.cpp:
        (JSC::toStringWithRadixInternal):

2018-01-23  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227424. rdar://problem/36791625

    2018-01-23  Filip Pizlo  <fpizlo@apple.com>

            JSC should use a speculation fence on VM entry/exit
            https://bugs.webkit.org/show_bug.cgi?id=181991

            Reviewed by JF Bastien and Mark Lam.

            This adds a WTF::speculationFence on VM entry and exit.

            For a microbenchmark that just calls a native function (supplied via an Objective-C block) in a
            tight loop from JS is a 0% regression on x86 and a 11% regression on ARM64.

            * runtime/JSLock.cpp:
            (JSC::JSLock::didAcquireLock):
            (JSC::JSLock::willReleaseLock):

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226895. rdar://problem/36568085

    2018-01-12  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Remove unnecessary raw pointer in InspectorConsoleAgent
            https://bugs.webkit.org/show_bug.cgi?id=181579
            <rdar://problem/36193759>

            Reviewed by Brian Burg.

            * inspector/agents/InspectorConsoleAgent.h:
            * inspector/agents/InspectorConsoleAgent.cpp:
            (Inspector::InspectorConsoleAgent::clearMessages):
            (Inspector::InspectorConsoleAgent::addConsoleMessage):
            Switch from a raw pointer to m_consoleMessages.last().
            Also move the expiration check into the if block since it can only
            happen inside here when the number of console messages changes.

            (Inspector::InspectorConsoleAgent::discardValues):
            Also clear the expired message count when messages are cleared.

2018-01-12  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226840. rdar://problem/36479468

    2018-01-11  Michael Saboff  <msaboff@apple.com>

            REGRESSION(226788): AppStore Crashed @ JavaScriptCore: JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters
            https://bugs.webkit.org/show_bug.cgi?id=181570

            Reviewed by Keith Miller.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::abortWithReason):
            Reverting these functions to use dataTempRegister and memoryTempRegister as they are
            JIT release asserts that will crash the program.

            (JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):
            Changed this so that it invalidates any cached dataTmpRegister contents if temp register
            caching is enabled.

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226788. rdar://problem/36450828

    2018-01-11  Michael Saboff  <msaboff@apple.com>

            Ensure there are no unsafe uses of MacroAssemblerARM64::dataTempRegister
            https://bugs.webkit.org/show_bug.cgi?id=181512

            Reviewed by Saam Barati.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::abortWithReason):
            (JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):
            All current uses of dataTempRegister in these functions are safe, but it makes sense to
            fix them in case they might be used elsewhere.

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226767. rdar://problem/36450818

    2018-01-11  Saam Barati  <sbarati@apple.com>

            Our for-in caching is wrong when we add indexed properties on things in the prototype chain
            https://bugs.webkit.org/show_bug.cgi?id=181508

            Reviewed by Yusuke Suzuki.

            Our for-in caching would cache structure chains that had prototypes with
            indexed properties. Clearly this is wrong. This caching breaks when a prototype
            adds new indexed properties. We would continue to enumerate the old cached
            state of properties, and not include the new indexed properties.

            The old code used to prevent caching only if the base structure had
            indexed properties. This patch extends it to prevent caching if the
            base, or any structure in the prototype chain, has indexed properties.

            * runtime/Structure.cpp:
            (JSC::Structure::canCachePropertyNameEnumerator const):

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226650. rdar://problem/36429150

    2018-01-09  Mark Lam  <mark.lam@apple.com>

            ASSERTION FAILED: pair.second->m_type & PropertyNode::Getter
            https://bugs.webkit.org/show_bug.cgi?id=181388
            <rdar://problem/36349351>

            Reviewed by Saam Barati.

            When there are duplicate setters or getters, we may end up overwriting a getter
            with a setter, or vice versa.  This patch adds tracking for getters/setters that
            have been overwritten with duplicates and ignore them.

            * bytecompiler/NodesCodegen.cpp:
            (JSC::PropertyListNode::emitBytecode):
            * parser/NodeConstructors.h:
            (JSC::PropertyNode::PropertyNode):
            * parser/Nodes.h:
            (JSC::PropertyNode::isOverriddenByDuplicate const):
            (JSC::PropertyNode::setIsOverriddenByDuplicate):

2018-01-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226672. rdar://problem/36397330

    2018-01-09  Keith Miller  <keith_miller@apple.com>

            and32 with an Address source on ARM64 did not invalidate dataTempRegister
            https://bugs.webkit.org/show_bug.cgi?id=181467

            Reviewed by Michael Saboff.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::and32):

2017-12-01  Saam Barati  <sbarati@apple.com>

        Having a bad time needs to handle ArrayClass indexing type as well
        https://bugs.webkit.org/show_bug.cgi?id=180274
        <rdar://problem/35667869>

        Reviewed by Keith Miller and Mark Lam.

        We need to make sure to transition ArrayClass to SlowPutArrayStorage as well.
        Otherwise, we'll end up with the wrong Structure, which will lead us to not
        adhere to the spec. The bug was that we were not considering ArrayClass inside 
        hasBrokenIndexing. This patch rewrites that function to automatically opt
        in non-empty indexing types as broken, instead of having to opt out all
        non-empty indexing types besides SlowPutArrayStorage.

        * runtime/IndexingType.h:
        (JSC::hasSlowPutArrayStorage):
        (JSC::shouldUseSlowPut):
        * runtime/JSGlobalObject.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::switchToSlowPutArrayStorage):

2016-11-14  Mark Lam  <mark.lam@apple.com>

        RegExpObject::exec/match should handle errors gracefully.
        https://bugs.webkit.org/show_bug.cgi?id=155145
        <rdar://problem/27435934>

        Reviewed by Keith Miller.

        1. Added some missing exception checks to RegExpObject::execInline() and
           RegExpObject::matchInline().
        2. Updated related code to work with ExceptionScope verification requirements.

        * dfg/DFGOperations.cpp:
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):

2016-03-07  Filip Pizlo  <fpizlo@apple.com>

        RegExp.prototype.exec() should call into Yarr at most once
        https://bugs.webkit.org/show_bug.cgi?id=155139

        Reviewed by Saam Barati.

        For apparently no good reason, RegExp.prototype.match() was calling into Yarr twice, almost
        as if it was hoping that the non-matching case was so common that it was best to have the
        matching case do the work all over again.

        This is a 4% speed-up on Octane/regexp. It's also a matter of common sense: we should not be
        in the business of presuming whether someone's match will succeed or fail. The increased
        cost of running Yarr twice is so much larger than whatever savings we were getting from
        running a match-only regexp that this is just not a good overall deal for the engine.

        Also, it's interesting that we are seeing a 4% speed-up on regexp despite the fact that a
        majority (almost a supermajority, I think) of calls into RegExp.prototype.match() are failed
        matches. So, this change is a 4% speed-up despite being a slow down on the common case. That
        tells you just how bad the old behavior was on the uncommon case.

        * runtime/MatchResult.h:
        (MatchResult::MatchResult):
        (MatchResult::failed):
        (MatchResult::operator bool):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::lastResult):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::setMultiline):
        (JSC::RegExpConstructor::multiline):
        (JSC::RegExpConstructor::performMatch):
        (JSC::RegExpConstructor::recordMatch):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):
        (JSC::createEmptyRegExpMatchesArray):
        (JSC::createStructureImpl):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::put):
        (JSC::getLastIndexAsUnsigned):
        (JSC::RegExpObject::exec):
        (JSC::RegExpObject::match):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::getLastIndex):
        (JSC::RegExpObject::test):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):

2016-10-21  Caitlin Potter  <caitp@igalia.com>

        [JSC] don't crash when arguments to `new Function()` produce unexpected AST
        https://bugs.webkit.org/show_bug.cgi?id=163748

        Reviewed by Mark Lam.

        The ASSERT(statement); and ASSERT(funcDecl); lines are removed, replaced with blocks
        to report a generic Parser error message. These lines are only possible to be reached
        if the input string produced an unexpected AST, which previously could be used to crash
        the process via ASSERT failure.

        The node type assertions are left in the tree, as it should be impossible for a top-level
        `{` to produce anything other than a Block node. If the node turns out not to be a Block,
        it indicates that the (C++) caller of this function (E.g in FunctionConstructor.cpp), is
        doing something incorrect. Similarly, it should be impossible for the `funcDecl` node to
        be anything other than a function declaration given the conventions of the caller of this
        function.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):

2016-02-02  Caitlin Potter  <caitp@igalia.com>

        JSSymbolTableObject::deleteProperty() crashes deleting Symbols
        https://bugs.webkit.org/show_bug.cgi?id=153816

        Reviewed by Darin Adler.

        Changes JSSymbolTableObject::deleteProperty() to check if its
        symbolTable() contains the property's uid() rather than publicName().
        This ensures that it will not crash in the case of Symbols.

        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::deleteProperty):
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (testGlobalProxy):
        * tests/stress/regress-153816.js: Added.
        (deleteSymbolFromJSSymbolTableObject):

2016-04-28  Skachkov Oleksandr  <gskachkov@gmail.com>

        Crash for non-static super property call in derived class constructor
        https://bugs.webkit.org/show_bug.cgi?id=157089

        Reviewed by Darin Adler.
       
        Added tdz check of the 'this' before access to the 'super' for FunctionCallBracketNode, 
        the same as it was done for FunctionCallDotNode.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallBracketNode::emitBytecode):

2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for super() call in direct eval in method function
        https://bugs.webkit.org/show_bug.cgi?id=157091

        Reviewed by Darin Adler.

        While we ensure that direct super is under the correct context,
        we don't check it for the eval code. This patch moves the check from the end of parsing the function
        to the places where we found the direct super or the super bindings. This covers the direct eval that
        contains the direct super calls.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::hasDirectSuper):
        (JSC::Scope::setHasDirectSuper):
        (JSC::Scope::needsSuperBinding):
        (JSC::Scope::setNeedsSuperBinding):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        * tests/stress/eval-and-super.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.m):
        (prototype.n):
        * tests/stress/generator-and-super.js: Added.
        (testSyntaxError):
        (testSyntaxError.Base.prototype.hello):
        (testSyntaxError.Base.prototype.ok):
        (testSyntaxError.Base):
        (Hello.prototype.gen):
        (Hello):
        (testSyntaxError.hello):

2016-02-08  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES6] Arrow function syntax. Using 'super' in arrow function that declared out of the class should lead to Syntax error
        https://bugs.webkit.org/show_bug.cgi?id=150893

        Reviewed by Saam Barati.

        'super' and 'super()' inside of the arrow function should lead to syntax error if they are used 
        out of the class context or they wrapped by ordinary function. Now JSC returns ReferenceError but 
        should return SyntaxError according to the following specs:
        http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
        and http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation 
        Curren patch implemented only one case when super/super() are used inside of the arrow function
        Case when super/super() are used within the eval:
           class A {} 
           class B extends A { 
               costructor() { eval("super()");} 
           }
        is not part of this patch and will be implemented in this issue https://bugs.webkit.org/show_bug.cgi?id=153864. 
        The same for case when eval with super/super() is invoked in arrow function will be 
        implemented in issue https://bugs.webkit.org/show_bug.cgi?id=153977. 
 
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setExpectedSuperBinding):
        (JSC::Scope::expectedSuperBinding):
        (JSC::Scope::setConstructorKind):
        (JSC::Scope::constructorKind):
        (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js:
        * tests/stress/arrowfunction-lexical-bind-superproperty.js:

2015-11-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        Super use should be recorded in per-function scope
        https://bugs.webkit.org/show_bug.cgi?id=151500

        Reviewed by Geoffrey Garen.

        "super" use is prohibited under the non-constructor / non-class-method-related functions.
        This "super" use should be recorded in per-function scope to check its incorrect use after
        parsing a function.
        Currently, we accidentally record it to a lexical current scope. So when using "super" inside
        a block scope, our "super" use guard miss it.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::currentVariableScope):
        (JSC::Parser::currentFunctionScope):
        (JSC::Parser::declareVariable):
        * tests/stress/super-in-lexical-scope.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.test):

2017-12-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r225239. rdar://problem/35838157

    2017-11-27  JF Bastien  <jfbastien@apple.com>

            JavaScript rest function parameter with negative index leads to bad DFG abstract interpretation
            https://bugs.webkit.org/show_bug.cgi?id=180051
            <rdar://problem/35614371>

            Reviewed by Saam Barati.

            Checking for int32 isn't sufficient when uint32 is expected
            afterwards. While we're here, also use Checked<>.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2017-11-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r224426. rdar://problem/35364697

    2017-11-03  Michael Saboff  <msaboff@apple.com>

            The Abstract Interpreter needs to change similar to clobberize() in r224366
            https://bugs.webkit.org/show_bug.cgi?id=179267

            Reviewed by Saam Barati.

            Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
            cases in the abstract interpreter to match what was done for r224366.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2017-11-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r224366. rdar://problem/35329723

    2017-11-02  Michael Saboff  <msaboff@apple.com>

            DFG needs to handle code motion of code in for..in loop bodies
            https://bugs.webkit.org/show_bug.cgi?id=179212

            Reviewed by Keith Miller.

            The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
            make calls with side effects.  Updated clobberize() for those nodes to take that into account.

            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):

2017-11-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r224349. rdar://problem/35329732

    2017-11-02  Filip Pizlo  <fpizlo@apple.com>

            AI does not correctly model the clobber case of ArithClz32
            https://bugs.webkit.org/show_bug.cgi?id=179188

            Reviewed by Michael Saboff.

            The non-Int32 case clobbers the world because it may call valueOf.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2017-11-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r224302. rdar://problem/35323829

    2017-11-01  Michael Saboff  <msaboff@apple.com>

            Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
            https://bugs.webkit.org/show_bug.cgi?id=179140

            Reviewed by Saam Barati.

            Added overflow checks to computation of arg count plus this.

            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):

2017-10-21  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r223645. rdar://problem/34820875

    2017-10-18  Mark Lam  <mark.lam@apple.com>

            RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
            https://bugs.webkit.org/show_bug.cgi?id=177600
            <rdar://problem/34710985>

            Reviewed by Saam Barati.

            According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
            section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
            descriptor value is present.

            * runtime/RegExpObject.cpp:
            (JSC::RegExpObject::defineOwnProperty):

2017-10-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r222417. rdar://problem/35010839

    2017-09-22  Fujii Hironori  <Hironori.Fujii@sony.com>

            [Win64] Crashes in Yarr JIT compiled code
            https://bugs.webkit.org/show_bug.cgi?id=177293

            Reviewed by Yusuke Suzuki.

            In x64 Windows, rcx register is used for the address of allocated
            space for the return value. But, rcx is used for regT1 since
            r221052. Save rcx in the stack.

            * yarr/YarrJIT.cpp:
            (JSC::Yarr::YarrGenerator::generateEnter): Push ecx.
            (JSC::Yarr::YarrGenerator::generateReturn): Pop ecx.

2017-10-02  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r221400. rdar://problem/34771396

    2017-08-30  Saam Barati  <sbarati@apple.com>

            semicolon is being interpreted as an = in the LiteralParser
            https://bugs.webkit.org/show_bug.cgi?id=176114

            Reviewed by Oliver Hunt.

            * stress/jsonp-literal-parser-semicolon-is-not-assignment.js: Added.            * stress/resources/literal-parser-test-case.js: Added.

2016-06-24  Mark Lam  <mark.lam@apple.com>

        [JSC] Error prototypes are called on remote scripts.
        https://bugs.webkit.org/show_bug.cgi?id=52192

        Reviewed by Keith Miller.

        Added a sanitizedToString() to the Error instance object so that it can be used
        to get an error string without invoking getters and proxies.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::createStructure):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):

2016-02-12  Keith Miller  <keith_miller@apple.com>

        AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself
        https://bugs.webkit.org/show_bug.cgi?id=154146

        Reviewed by Filip Pizlo.

        Consider the following: there is some CodeBlock, C, that is watching some object, O, with a
        structure, S, for replacements. Also, suppose that C has no references anymore and is due to
        be GCed. Now, when some new property is added to O, S will create a new structure S' and
        fire its transition watchpoints. Since C is watching S for replacements it will attempt to
        have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs
        it allocate RareData on S'. This allocation may cause a GC, which frees C while still
        executing its watchpoint handler. The solution to this is to defer GC while running
        AdaptiveInferredPropertyValueWatchpointBase handlers.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):

2017-05-10  Filip Pizlo  <fpizlo@apple.com>

        Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
        https://bugs.webkit.org/show_bug.cgi?id=171801

        Reviewed by Michael Saboff.
        
        This was a goofy oversight. The for-in optimization relies on the bytecode generator
        to detect when the loop's index variable gets mutated. We forgot to have the hooks for
        detecting this in prefix and postfix operations (++i and i++).

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):

2017-05-18  Filip Pizlo  <fpizlo@apple.com>

        Constructor calls set this too early
        https://bugs.webkit.org/show_bug.cgi?id=172302

        Reviewed by Saam Barati.
        
        We were setting this before evaluating the arguments, so this code:
        
            var x = 42;
            new x(x = function() { });
        
        Would crash because we would pass 42 as this, and create_this would treat it as a cell.
        Dereferencing a non-cell is guaranteed to crash.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):

2015-08-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        JavascriptCore Crash in JSC::ASTBuilder::Property JSC::Parser<JSC::Lexer<unsigned char> >::parseProperty<JSC::ASTBuilder>(JSC::ASTBuilder&, bool)
        https://bugs.webkit.org/show_bug.cgi?id=147538

        Reviewed by Geoffrey Garen.

        Due to the order of the ARROWFUNCTION token in JSTokenType enum, it is categorized as the one of the Keyword.
        As a result, when lexing the property name that can take the keywords, the ARROWFUNCTION token is accidentally accepted.
        This patch changes the order of the ARROWFUNCTION token in JSTokenType to make it the operator token.

        * parser/ParserTokens.h:
        * tests/stress/arrow-function-token-is-not-keyword.js: Added.
        (testSyntaxError):

2017-09-27  Mark Lam  <mark.lam@apple.com>

        JSArray::canFastCopy() should fail if the source and destination arrays are the same.
        https://bugs.webkit.org/show_bug.cgi?id=177584
        <rdar://problem/34463903>

        Reviewed by Saam Barati.

        If the source and destination arrays are the same, we may be copying overlapping
        regions.  Hence, we need to take the slow path.

        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canFastCopy):

2017-10-19  Mark Lam  <mark.lam@apple.com>

        Stringifier::appendStringifiedValue() is missing an exception check.
        https://bugs.webkit.org/show_bug.cgi?id=178386
        <rdar://problem/35027610>

        Reviewed by Saam Barati.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2017-11-03  Keith Miller  <keith_miller@apple.com>

        PutProperytSlot should inform the IC about the property before effects.
        https://bugs.webkit.org/show_bug.cgi?id=179262

        Reviewed by Mark Lam.

        This patch fixes an issue where we choose to cache setters based on
        incorrect information. If we did so we might end up OSR exiting
        more than we would otherwise need to. The new model is that the
        PutPropertySlot should inform the IC of what the property looked
        like before any potential side effects might have occurred.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/Lookup.h:
        (JSC::putEntry):

2017-06-30  Michael Saboff  <msaboff@apple.com>

        RegExp's  anchored with .* with \g flag can return wrong match start for strings with multiple matches
        https://bugs.webkit.org/show_bug.cgi?id=174044

        Reviewed by Oliver Hunt.

        The .* enclosure optimization didn't respect that we can start matching from a non-zero
        index.  This optimization treats /.*<some-terms>.*/ by first matching the <some-terms> and
        then finding the extent of the match by going back to the beginning of the line and going
        forward to the end of the line.  The code that went back to the beginning of the line
        checked for an index of 0 instead of comparing the index to the start position.  This start
        position is passed as the initial index.

        Added another temporary register to the YARR JIT to contain the start position for
        platforms that have spare registers.

        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::matchDotStarEnclosure):
        (JSC::Yarr::Interpreter::Interpreter):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):

2015-09-09  Chris Dumez  <cdumez@apple.com>

        HTMLTableElement.tHead / tFoot / caption should be nullable
        https://bugs.webkit.org/show_bug.cgi?id=148991

        Reviewed by Ryosuke Niwa.

        According to the specification, HTMLTableElement.tHead / tFoot / caption
        should be nullable:
        https://html.spec.whatwg.org/multipage/tables.html#htmltableelement

        Upon assigning null, we are supposed to remove the existing tHead / tFoot
        / caption element. However, we had a bug causing us to throw an exception
        after removing the element. This is because we would try to insert a null
        element and ContainerNode::insertBefore() throws when doing so.

        Also, as per the specification, setting tHead / tFoot to something else
        than a thead / tfoot element should throw a HierarchyRequestError:
        https://html.spec.whatwg.org/multipage/tables.html#dom-table-thead
        https://html.spec.whatwg.org/multipage/tables.html#dom-table-tfoot

        Previously, WebKit did not check the tag and was happy inserting the
        element as long as it was an HTMLTableSectionElement. This means that
        you could set a tfoot by assigning table.tHead.

        This patch corrects both bugs and adds test coverage for it.

        Test: fast/dom/HTMLTableElement/nullable-attributes.html

        * html/HTMLTableElement.cpp:
        (WebCore::HTMLTableElement::setCaption):
        Only call insertBefore() if newCaption is not null as insertBefore()
        will throw an exception otherwise.

        (WebCore::HTMLTableElement::setTHead):
        - Throw a HierarchyRequestError if the HTMLTableSectionElement is not
          null or a <thead> element, as per the specification.
        - Only call insertBefore() if newHead is not null as insertBefore()
          will throw an exception otherwise.

        (WebCore::HTMLTableElement::setTFoot):
        - Throw a HierarchyRequestError if the HTMLTableSectionElement is not
          null or a <tfoot> element, as per the specification.
        - Only call insertBefore() if newFoot is not null as insertBefore()
          will throw an exception otherwise.

        * html/HTMLTableElement.idl:
        Use [StrictTypeChecking] for these 3 attributes so that the bindings
        will throw a TypeError if the JS tries to assign a value with the
        wrong type. When the implementation is called with null, we now know
        this is because the JS assigned null (and not an invalid value).
        This is important as assigning null is valid since those attributes
        are nullable.

2017-06-30  Filip Pizlo  <fpizlo@apple.com>

        RegExpCachedResult::setInput should reify left and right contexts
        https://bugs.webkit.org/show_bug.cgi?id=173818

        Reviewed by Keith Miller.
       
        If you don't reify them in setInput, then when you later try to reify them, you'll end up
        using indices into an old input string to create a substring of a new input string. That
        never goes well.

        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::setInput):

2017-06-06  Mark Lam  <mark.lam@apple.com>

        Contiguous storage butterfly length should not exceed MAX_STORAGE_VECTOR_LENGTH.
        https://bugs.webkit.org/show_bug.cgi?id=173035
        <rdar://problem/32554593>

        Reviewed by Geoffrey Garen and Filip Pizlo.

        Also added and fixed up some assertions.

        * runtime/ArrayConventions.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * runtime/JSObject.cpp:
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSplitFast):

2017-05-11  Filip Pizlo  <fpizlo@apple.com>

        Callers of JSString::unsafeView() should check exceptions
        https://bugs.webkit.org/show_bug.cgi?id=171995

        Reviewed by Mark Lam.
        
        unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
        to access the view.

        Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
        the rest of JSC.

        * dfg/DFGOperations.cpp:
        * jsc.cpp:
        (printInternal):
        (functionDebug):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncJoin):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorFuncCompare):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncJoin):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncParseFloat):
        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse):
        * runtime/JSString.cpp:
        (JSC::JSString::getPrimitiveNumber):
        (JSC::JSString::toNumber):
        * runtime/JSString.h:
        (JSC::JSString::getIndex):
        (JSC::JSRopeString::unsafeView):
        (JSC::JSRopeString::viewWithUnderlyingString):
        (JSC::JSString::unsafeView):
        (JSC::JSString::viewWithUnderlyingString):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::appendWithoutSideEffects):
        (JSC::JSStringJoiner::append):
        * runtime/ParseInt.h:
        (JSC::toStringView):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncRepeatCharacter):
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCharCodeAt):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncNormalize):

2017-05-09  Filip Pizlo  <fpizlo@apple.com>

        JSInjectedScriptHost should get a copy of the boundArgs
        https://bugs.webkit.org/show_bug.cgi?id=171897

        Reviewed by Joseph Pecoraro.
        
        The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
        for the inspector to get a copy of it.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::boundArgsCopy):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::boundArgs):

2017-07-06  Saam Barati  <sbarati@apple.com>

        We are missing places where we invalidate the for-in context
        https://bugs.webkit.org/show_bug.cgi?id=174184

        Reviewed by Geoffrey Garen.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::invalidateForInContextForLocal):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::EmptyLetExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue):

2016-10-31  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Provide an opportunity to clear ScriptValues associated with debugged target
        https://bugs.webkit.org/show_bug.cgi?id=164167
        <rdar://problem/29010148>

        Reviewed by Mark Lam.

        * inspector/InspectorAgentBase.h:
        (Inspector::InspectorAgentBase::discardValues):
        * inspector/InspectorAgentRegistry.cpp:
        (Inspector::AgentRegistry::~AgentRegistry):
        (Inspector::AgentRegistry::discardValues):
        * inspector/InspectorAgentRegistry.h:
        New standard agent method to allow the agent to discard values.

        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::discardValues):
        Discard ScriptValues in ConsoleMessages.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
        Global object is going away, discard values.

2015-09-04  Brian Burg  <bburg@apple.com>

        Web Inspector: InspectorController should support multiple frontend channels
        https://bugs.webkit.org/show_bug.cgi?id=148538

        Reviewed by Joseph Pecoraro.

        Instead of a singleton, it should be possible to have multiple channels open
        at the same time and to individually close channels as frontends come and go.

        The FrontendRouter class keeps a list of open FrontendChannels and sends messages
        to the appropriate frontends based on whether the message is a response or event.
        Each InspectorController owns a single FrontendRouter and BackendDispatcher instance.
        Inspector backend code that sends messages to the frontend should switch over to
        using the router rather than directly using a FrontendChannel.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InspectorBackendDispatcher.cpp: Move constructors/destructors out of the header
        to avoid including InspectorFrontendRouter everywhere. Use the router instead of a
        specific frontend channel. Remove guards that are no longer necessary since the router
        is guaranteed to outlive the backend dispatcher.

        (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
        (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
        (Inspector::BackendDispatcher::BackendDispatcher):
        (Inspector::BackendDispatcher::create):
        (Inspector::BackendDispatcher::isActive):
        (Inspector::BackendDispatcher::registerDispatcherForDomain):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::BackendDispatcher::sendPendingErrors):
        * inspector/InspectorBackendDispatcher.h:
        (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher): Deleted.
        (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher): Deleted.
        (Inspector::BackendDispatcher::clearFrontend): Deleted, no longer necessary.
        (Inspector::BackendDispatcher::isActive): Moved to implementation file.
        (Inspector::BackendDispatcher::BackendDispatcher): Moved to implementation file.
        * inspector/InspectorFrontendRouter.cpp: Added.
        (Inspector::FrontendRouter::create):
        (Inspector::FrontendRouter::connectFrontend):
        (Inspector::FrontendRouter::disconnectFrontend):
        (Inspector::FrontendRouter::disconnectAllFrontends):
        (Inspector::FrontendRouter::leakChannel):
        (Inspector::FrontendRouter::hasLocalFrontend):
        (Inspector::FrontendRouter::hasRemoteFrontend):
        (Inspector::FrontendRouter::sendEvent):
        (Inspector::FrontendRouter::sendResponse):
        * inspector/InspectorFrontendRouter.h: Added.
        * inspector/JSGlobalObjectInspectorController.cpp: Remove guards that are no longer necessary.
        The frontend router and backend dispatcher now have the same lifetime as the controller.
        Explicitly connect/disconnect the frontend channel.

        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
        (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        * inspector/agents/InspectorConsoleAgent.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        * inspector/augmentable/AugmentableInspectorController.h:
        (Inspector::AugmentableInspectorController::connected):
        * inspector/remote/RemoteInspectorDebuggable.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorDebuggableConnection::close):
        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event): Use the router.
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::disconnect):
        * runtime/JSGlobalObjectDebuggable.h:

2015-08-27  Brian Burg  <bburg@apple.com>

        Web Inspector: FrontendChannel should know its own connection type
        https://bugs.webkit.org/show_bug.cgi?id=148482

        Reviewed by Joseph Pecoraro.

        * inspector/InspectorFrontendChannel.h: Add connectionType().
        * inspector/remote/RemoteInspectorDebuggableConnection.h:

2016-02-12  Gavin Barraclough  <barraclough@apple.com>

        Separate out !allowsAccess path in JSDOMWindowCustom getOwnPropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=154156

        Reviewed by Chris Dumez.

        * runtime/CommonIdentifiers.h:
            - added new property names, needed by jsDOMWindowGetOwnPropertySlotDisallowAccess.

2017-01-17  Michael Saboff  <msaboff@apple.com>

        Nested parenthesized regular expressions with non-zero minimum counts appear to hang and use lots of memory
        https://bugs.webkit.org/show_bug.cgi?id=167125

        Reviewed by Filip Pizlo.

        Changed Yarr to handle nested parenthesized subexpressions where the minimum count is
        not 0 directly in the Yarr interpreter.  Previously we'd factor an expression like
        (a|b)+ into (a|b)(a|b)* with special handling for captures.  This factoring was done
        using a deep copy that doubled the size of the resulting expresion for each nested 
        parenthesized subexpression.  Now the Yarr interpreter can directly process a regexp
        like (a|b){2,42}.  

        The parser will allow one level of nested, non-zero minimum, counted parenthesis using
        the old copy method.  After one level, it will generate parenthesis terms with a non-zero
        minimum.   Such an expression wasn't handled by the Yarr JIT before the change, so this
        change isn't a performance regression.

        Added a minimum count to the YarrPattern and ByteTerm classes, and then factored that
        minimum into the interpreter.  A non-zero minimum is only handled by the Yarr interpreter.
        If the Yarr JIT see such a term, it punts back to the interpreter.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::backtrackPatternCharacter):
        (JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
        (JSC::Yarr::Interpreter::matchCharacterClass):
        (JSC::Yarr::Interpreter::backtrackCharacterClass):
        (JSC::Yarr::Interpreter::matchBackReference):
        (JSC::Yarr::Interpreter::backtrackBackReference):
        (JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
        (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
        (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
        (JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
        (JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
        (JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
        (JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
        (JSC::Yarr::Interpreter::matchParentheses):
        (JSC::Yarr::Interpreter::backtrackParentheses):
        (JSC::Yarr::Interpreter::matchDisjunction):
        (JSC::Yarr::ByteCompiler::atomPatternCharacter):
        (JSC::Yarr::ByteCompiler::atomCharacterClass):
        (JSC::Yarr::ByteCompiler::atomBackReference):
        (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generateTerm):
        (JSC::Yarr::YarrGenerator::backtrackTerm):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::copyTerm):
        (JSC::Yarr::YarrPatternConstructor::quantifyAtom):
        (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::PatternTerm):
        (JSC::Yarr::PatternTerm::quantify):
        (JSC::Yarr::YarrPattern::reset):

2017-05-05  Saam Barati  <sbarati@apple.com>

        putDirectIndex does not properly do defineOwnProperty
        https://bugs.webkit.org/show_bug.cgi?id=171591
        <rdar://problem/31735695>

        Reviewed by Geoffrey Garen.

        This patch fixes putDirectIndex and its JIT implementations to be
        compatible with the ES6 spec. I think our code became out of date
        when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
        return arbitrary objects. We perform putDirectIndex on that arbitrary
        object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
        However, we weren't doing this. putDirectIndex assumed it could just splat
        data into any descendent of JSObject's butterfly. For example, this means
        we'd just splat into the butterfly of a typed array, even though a typed
        array doesn't use its butterfly to store its indexed properties in the usual
        way. Also, typed array properties are non-configurable, so this operation
        should throw. This also means if we saw a ProxyObject, we'd just splat
        into its butterfly, but this is obviously wrong because ProxyObject should
        intercept the defineProperty operation.
        
        This patch fixes this issue by adding a whitelist of cell types that can
        go down putDirectIndex's fast path. Anything not in that whitelist will
        simply call into defineOwnProperty.

        * bytecode/ByValInfo.h:
        (JSC::jitArrayModePermitsPutDirect):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createStructure):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * runtime/JSObject.cpp:
        (JSC::canDoFastPutDirectIndex):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
        * runtime/JSType.h:

2017-03-23  Mark Lam  <mark.lam@apple.com>

        Array.prototype.splice behaves incorrectly when the VM is "having a bad time".
        https://bugs.webkit.org/show_bug.cgi?id=170025
        <rdar://problem/31228679>

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        (JSC::copySplicedArrayElements):
        (JSC::arrayProtoFuncSplice):

2017-03-16  Mark Lam  <mark.lam@apple.com>

        Array concat operation should check for length overflows.
        https://bugs.webkit.org/show_bug.cgi?id=169796
        <rdar://problem/31095276>

        Reviewed by Keith Miller.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):

2017-03-10  Mark Lam  <mark.lam@apple.com>

        JSC: BindingNode::bindValue doesn't increase the scope's reference count.
        https://bugs.webkit.org/show_bug.cgi?id=168546
        <rdar://problem/30589551>

        Reviewed by Saam Barati.

        We should protect the scope RegisterID with a RefPtr while it is still needed.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue):

2017-03-09  Filip Pizlo  <fpizlo@apple.com>

        WebKit: JSC: JSObject::ensureLength doesn't check if ensureLengthSlow failed
        https://bugs.webkit.org/show_bug.cgi?id=169215

        Reviewed by Mark Lam.
        
        This doesn't have a test because it would be a very complicated test.

        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength): If ensureLengthSlow returns false, we need to return false.

2017-05-05  Keith Miller  <keith_miller@apple.com>

        Put does not properly consult the prototype chain
        https://bugs.webkit.org/show_bug.cgi?id=171754

        Reviewed by Saam Barati.

        We should do a follow up that cleans up the rest of put. See:
        https://bugs.webkit.org/show_bug.cgi?id=171759

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):

2017-05-05  Saam Barati  <sbarati@apple.com>

        putDirectIndex does not properly do defineOwnProperty
        https://bugs.webkit.org/show_bug.cgi?id=171591
        <rdar://problem/31735695>

        Reviewed by Geoffrey Garen.

        This patch fixes putDirectIndex and its JIT implementations to be
        compatible with the ES6 spec. I think our code became out of date
        when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
        return arbitrary objects. We perform putDirectIndex on that arbitrary
        object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
        However, we weren't doing this. putDirectIndex assumed it could just splat
        data into any descendent of JSObject's butterfly. For example, this means
        we'd just splat into the butterfly of a typed array, even though a typed
        array doesn't use its butterfly to store its indexed properties in the usual
        way. Also, typed array properties are non-configurable, so this operation
        should throw. This also means if we saw a ProxyObject, we'd just splat
        into its butterfly, but this is obviously wrong because ProxyObject should
        intercept the defineProperty operation.
        
        This patch fixes this issue by adding a whitelist of cell types that can
        go down putDirectIndex's fast path. Anything not in that whitelist will
        simply call into defineOwnProperty.

        * bytecode/ByValInfo.h:
        (JSC::jitArrayModePermitsPutDirect):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createStructure):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * runtime/JSObject.cpp:
        (JSC::canDoFastPutDirectIndex):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
        * runtime/JSType.h:

2017-03-23  Mark Lam  <mark.lam@apple.com>

        Clients of JSArray::tryCreateForInitializationPrivate() should do their own null checks.
        https://bugs.webkit.org/show_bug.cgi?id=169783

        Reviewed by Saam Barati.

        Fixed clients of tryCreateForInitializationPrivate() to do a null check and throw
        an OutOfMemoryError if allocation fails, or RELEASE_ASSERT that the allocation
        succeeds.

        * dfg/DFGOperations.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateForInitializationPrivate):
        (JSC::JSArray::fastSlice):
        * runtime/JSArray.h:
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createEmptyRegExpMatchesArray):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):

2017-07-13  Mark Lam  <mark.lam@apple.com>

        JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
        https://bugs.webkit.org/show_bug.cgi?id=170896
        <rdar://problem/31651319>

        Reviewed by JF Bastien and Keith Miller.

        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):

2015-10-15  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r190289): Repro crash clicking back button on netflix.com
        https://bugs.webkit.org/show_bug.cgi?id=150220

        Reviewed by Geoffrey Garen.

        Since constructors check for a valid new "this" object and return it, we can't make
        a tail call to another function from within a constructor.

        Re-enabled the tail calls and the related tail call tests.

        Did some other miscellaneous clean up in the tail call code as part of the debugging.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * runtime/Options.h:
        * tests/es6.yaml:
        * tests/stress/dfg-tail-calls.js:
        (nonInlinedTailCall.callee):
        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-in-inline-cache.js:
        (tail):
        * tests/stress/tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-recognize.js:
        (callerMustBeRun):
        * tests/stress/tail-call-varargs-no-stack-overflow.js:
        (shouldThrow):

2015-10-14  Mark Lam  <mark.lam@apple.com>

        Rename some JSC option names to be more uniform.
        https://bugs.webkit.org/show_bug.cgi?id=150127

        Reviewed by Geoffrey Garen.

        Renaming JSC_enableXXX options to JSC_useXXX, and JSC_showXXX options to JSC_dumpXXX.
        Also will renaming a few other miscellaneous to options, to abide by this scheme.

        Also renaming some functions to match the option names where relevant.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * assembler/AbstractMacroAssembler.h:
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::optimizeForARM64):
        (JSC::optimizeForX86):
        * assembler/LinkBuffer.cpp:
        (JSC::shouldDumpDisassemblyFor):
        (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
        (JSC::shouldShowDisassemblyFor): Deleted.
        * assembler/LinkBuffer.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlockJettisoningWatchpoint.cpp:
        (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCommon.h:
        (JSC::DFG::leastUpperBound):
        (JSC::DFG::shouldDumpDisassembly):
        (JSC::DFG::shouldShowDisassembly): Deleted.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJumpReplacement.cpp:
        (JSC::DFG::JumpReplacement::fire):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitFuzz.h:
        (JSC::DFG::doOSRExitFuzzing):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSqrt):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::~JITCode):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.h:
        (JSC::FTL::verboseCompilationEnabled):
        (JSC::FTL::shouldDumpDisassembly):
        (JSC::FTL::shouldShowDisassembly): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::shouldDoFullCollection):
        * heap/Heap.h:
        (JSC::Heap::isDeferred):
        (JSC::Heap::structureIDTable):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::storageCapacity):
        (JSC::HeapStatistics::dumpObjectStatistics):
        (JSC::HeapStatistics::showObjectStatistics): Deleted.
        * heap/HeapStatistics.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::callExceptionFuzz):
        * jit/ExecutableAllocationFuzz.cpp:
        (JSC::doExecutableAllocationFuzzing):
        * jit/ExecutableAllocationFuzz.h:
        (JSC::doExecutableAllocationFuzzingIfEnabled):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCode.cpp:
        (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::unlinkFor):
        (JSC::linkVirtualFor):
        * jsc.cpp:
        (functionEnableExceptionFuzz):
        (jscmain):
        * llvm/InitializeLLVM.cpp:
        (JSC::initializeLLVMImpl):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionFuzz.h:
        (JSC::doExceptionFuzzingIfEnabled):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        (JSC::Options::dumpOptionsIfNeeded):
        (JSC::Options::setOption):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpAllOptionsInALine):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::exceptionFuzzingBuffer):
        * runtime/WriteBarrierInlines.h:
        (JSC::WriteBarrierBase<T>::set):
        (JSC::WriteBarrierBase<Unknown>::set):
        * tests/executableAllocationFuzz.yaml:
        * tests/stress/arrowfunction-typeof.js:
        * tests/stress/disable-function-dot-arguments.js:
        (foo):
        * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js:
        (sqrtOnInteger):
        * tests/stress/regress-148564.js:

2017-03-24  Mark Lam  <mark.lam@apple.com>

        Array memcpy'ing fast paths should check if we're having a bad time if they cannot handle it.
        https://bugs.webkit.org/show_bug.cgi?id=170064
        <rdar://problem/31246098>

        Reviewed by Geoffrey Garen.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice):

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Add support for Symbol.isConcatSpreadable (round 2)
        https://bugs.webkit.org/show_bug.cgi?id=158769

        Reviewed by Mark Lam.

        This patch adds support for Symbol.isConcatSpreadable. In order to
        do so, it was necessary to move the Array.prototype.concat function
        to JS. A number of different optimizations were needed to make
        such the move to a builtin performant. First, this patch adds a
        new Bytecode intrinsic, isJSArray, that checks if the value is a
        JSArray object. Specifically, isJSArray checks that the array
        object is a normal instance of JSArray and not a RuntimeArray or
        Array.prototype. isJSArray can also be converted into a constant
        by the DFG if we are able to prove that the incomming value is
        already a JSArray.

        In order to further improve the perfomance we also now cover more
        indexing types in our fast path memcpy code. Before we would only
        memcpy Arrays if they had the same indexing type and did not have
        Array storage or were undecided. Now the memcpy code covers the
        following additional three cases:

        1) One array is undecided and the other does not have array storage

        2) One array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        3) The this value is an array and first argument is a non-array
        that does not have Symbol.isConcatSpreadable set.

        This patch also adds a new fast path for concat with more than one
        array argument by using memcpy to append values onto the result
        array. This works roughly the same as the two array fast path
        using the same methodology to decide if we can memcpy the other
        butterfly into the result butterfly.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsJSArray):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::speciesWatchpointsValid):
        (JSC::speciesConstructArray):
        (JSC::moveElements):
        (JSC::concatAppendOne):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IndexingType.h:
        (JSC::indexingTypeForValue):
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::isJSArray):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::mergeIndexingTypeForCopying):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::convertUndecidedForValue):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

2016-03-03  Keith Miller  <keith_miller@apple.com>

        Array prototype JS builtins should support Symbol.species
        https://bugs.webkit.org/show_bug.cgi?id=154710

        Reviewed by Geoffrey Garen.

        Add support for Symbol.species in the Array.prototype JS
        builtin functions.

        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/stress/array-species-functions.js:
        (id):

2016-06-12  Keith Miller  <keith_miller@apple.com>

        Add new builtin opcode tailCallForwardArguments
        https://bugs.webkit.org/show_bug.cgi?id=158666

        Reviewed by Filip Pizlo.

        We should support the ability to have a builtin forward its
        arguments to a helper without allocating an arguments object. This
        patch adds a new bytecode intrinsic @tailCallForwardArguments that
        takes two values. The first is the target of the call and the
        second is the new this value. This opcode will tail call to the
        passed function without triggering an allocation of an arguments
        object for the caller function.

        In the LLInt and Baseline this function acts the same way a normal
        tail call does.  The bytecode will allocate a new stack frame
        copying all the arguments of the caller function into the new
        frame, along with the new this. Then when the actual call happens
        the new frame is copied over the caller frame. While this is not
        necessary, it allows the target function to have more arguments
        than the caller function via arity fixup.

        Once we get to the DFG we reuse existing DFG Nodes for forwarding
        arguments, although there were some minor changes. This patch
        swaps the meaning of the second and third children for each DFG
        varargs node, exchanging the argmuments and this child,
        respectively. It also makes the arguments child for each varargs
        node, as well as the ForwardVarargs node optional. If the optional
        child is missing, then forwarding node assumes that the arguments
        for the node's inlineCallFrame should be used instead. Finally,
        when inlining the target of an inlined
        op_tail_call_forward_arguments we make sure the arguments of the
        forwarding function are marked as non-unboxable since this would
        normally be done by the caller's create arguments object node,
        which does not exist in this case.

        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargs):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArgumentsChild):
        (JSC::DFG::Node::argumentsChild):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        * interpreter/Interpreter.cpp:
        (JSC::sizeFrameForForwardArguments):
        (JSC::setupForwardArgumentsFrame):
        (JSC::setupForwardArgumentsFrameAndSetThis):
        * interpreter/Interpreter.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::varargsSetup):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * tests/stress/tailCallForwardArguments.js: Added.
        (putFuncToPrivateName.createBuiltin):
        (putFuncToPrivateName):
        (createTailCallForwardingFuncWith):
        (baz):
        (baz2):
        (baz3):
        (let.bodyText):
        (baz4):
        (baz5):
        (arrayEq):

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Mark Lam.

        JavaScriptCore now provides a sampling profiler and it is enabled
        by all ports. Web Inspector switched months ago to using the
        sampling profiler and displaying its data. Remove the legacy
        profiler, as it is no longer being used by anything other then
        console.profile and tests. We will update console.profile's
        behavior soon to have new behavior and use the sampling data.

        * API/JSProfilerPrivate.cpp: Removed.
        * API/JSProfilerPrivate.h: Removed.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister): Deleted.
        (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::CallArguments::CallArguments): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()): Deleted.
        (JSC::Interpreter::execute): Deleted.
        (JSC::Interpreter::executeCall): Deleted.
        (JSC::Interpreter::executeConstruct): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Removed.
        * profiler/LegacyProfiler.cpp: Removed.
        * profiler/LegacyProfiler.h: Removed.
        * profiler/Profile.cpp: Removed.
        * profiler/Profile.h: Removed.
        * profiler/ProfileGenerator.cpp: Removed.
        * profiler/ProfileGenerator.h: Removed.
        * profiler/ProfileNode.cpp: Removed.
        * profiler/ProfileNode.h: Removed.
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal): Deleted.
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
        (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
        (JSC::VM::setEnabledProfiler): Deleted.
        * runtime/VM.h:
        (JSC::VM::enabledProfiler): Deleted.
        (JSC::VM::enabledProfilerAddress): Deleted.

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Saam Barati.

        * inspector/protocol/Timeline.json:
        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasLegacyProfiler):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.

2015-09-24  Michael Saboff  <msaboff@apple.com>

        [ES6] Implement tail calls in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=148663

        Reviewed by Filip Pizlo.

        jsc-tailcall: Implement the tail call opcodes in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=146850

        This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:

         - TailCall and TailCallVarargs are straightforward. They are terminal
           nodes and have the semantics of an actual tail call.

         - TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
           tail call inside an inlined function. They are non terminal nodes,
           and are performing the call as a regular call after popping an
           appropriate number of inlined tail call frames.

         - TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
           extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
           the varargs forwarding optimization so that we don't lose
           performance with a tail call instead of a regular call.

        This also required two broad kind of changes:

         - Changes in the JIT itself (DFGSpeculativeJIT) are pretty
           straightforward since they are just an extension of the baseline JIT
           changes introduced previously.

         - Changes in the runtime are mostly related with handling inline call
           frames. The idea here is that we have a special TailCall type for
           call frames that indicates to the various pieces of code walking the
           inline call frame that they should (recursively) skip the caller in
           their analysis.

        * bytecode/CallMode.h:
        (JSC::specializationKindFor):
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::inlineDepthForCallFrame):
        (JSC::CodeOrigin::isApproximatelyEqualTo):
        (JSC::CodeOrigin::approximateHash):
        (JSC::CodeOrigin::inlineStack):
        * bytecode/CodeOrigin.h:
        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::dumpInContext):
        (WTF::printInternal):
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::callModeFor):
        (JSC::InlineCallFrame::kindFor):
        (JSC::InlineCallFrame::varargsKindFor):
        (JSC::InlineCallFrame::specializationKindFor):
        (JSC::InlineCallFrame::isVarargs):
        (JSC::InlineCallFrame::isTail):
        (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
        (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
        (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCallFrame):
        (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
        (JSC::DFG::ByteCodeParser::currentCodeOrigin):
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getPrediction):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCallVarargsData):
        (JSC::DFG::Node::isTerminal):
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::osrWriteBarrier):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::bytecodeOffset):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):

2015-08-18  Geoffrey Garen  <ggaren@apple.com>

        Split InlineCallFrame into its own file
        https://bugs.webkit.org/show_bug.cgi?id=148131

        Reviewed by Saam Barati.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallLinkStatus.cpp:
        * bytecode/CodeBlock.h:
        (JSC::ExecState::r):
        (JSC::baselineCodeBlockForInlineCallFrame): Deleted.
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock): Deleted.
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::inlineStack):
        (JSC::CodeOrigin::codeOriginOwner):
        (JSC::CodeOrigin::stackOffset):
        (JSC::CodeOrigin::dump):
        (JSC::CodeOrigin::dumpInContext):
        (JSC::InlineCallFrame::calleeConstant): Deleted.
        (JSC::InlineCallFrame::visitAggregate): Deleted.
        (JSC::InlineCallFrame::calleeForCallFrame): Deleted.
        (JSC::InlineCallFrame::hash): Deleted.
        (JSC::InlineCallFrame::hashAsStringIfPossible): Deleted.
        (JSC::InlineCallFrame::inferredName): Deleted.
        (JSC::InlineCallFrame::baselineCodeBlock): Deleted.
        (JSC::InlineCallFrame::dumpBriefFunctionInformation): Deleted.
        (JSC::InlineCallFrame::dumpInContext): Deleted.
        (JSC::InlineCallFrame::dump): Deleted.
        (WTF::printInternal): Deleted.
        * bytecode/CodeOrigin.h:
        (JSC::CodeOrigin::deletedMarker):
        (JSC::CodeOrigin::hash):
        (JSC::CodeOrigin::operator==):
        (JSC::CodeOriginHash::hash):
        (JSC::CodeOriginHash::equal):
        (JSC::InlineCallFrame::kindFor): Deleted.
        (JSC::InlineCallFrame::varargsKindFor): Deleted.
        (JSC::InlineCallFrame::specializationKindFor): Deleted.
        (JSC::InlineCallFrame::isVarargs): Deleted.
        (JSC::InlineCallFrame::InlineCallFrame): Deleted.
        (JSC::InlineCallFrame::specializationKind): Deleted.
        (JSC::InlineCallFrame::setStackOffset): Deleted.
        (JSC::InlineCallFrame::callerFrameOffset): Deleted.
        (JSC::InlineCallFrame::returnPCOffset): Deleted.
        (JSC::CodeOrigin::stackOffset): Deleted.
        (JSC::CodeOrigin::codeOriginOwner): Deleted.
        * bytecode/InlineCallFrame.cpp: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.cpp.
        (JSC::InlineCallFrame::calleeConstant):
        (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
        (JSC::CodeOrigin::inlineDepth): Deleted.
        (JSC::CodeOrigin::isApproximatelyEqualTo): Deleted.
        (JSC::CodeOrigin::approximateHash): Deleted.
        (JSC::CodeOrigin::inlineStack): Deleted.
        (JSC::CodeOrigin::dump): Deleted.
        (JSC::CodeOrigin::dumpInContext): Deleted.
        * bytecode/InlineCallFrame.h: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.h.
        (JSC::InlineCallFrame::isVarargs):
        (JSC::InlineCallFrame::InlineCallFrame):
        (JSC::InlineCallFrame::specializationKind):
        (JSC::baselineCodeBlockForInlineCallFrame):
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
        (JSC::CodeOrigin::CodeOrigin): Deleted.
        (JSC::CodeOrigin::isSet): Deleted.
        (JSC::CodeOrigin::operator!): Deleted.
        (JSC::CodeOrigin::isHashTableDeletedValue): Deleted.
        (JSC::CodeOrigin::operator!=): Deleted.
        (JSC::CodeOrigin::deletedMarker): Deleted.
        (JSC::CodeOrigin::stackOffset): Deleted.
        (JSC::CodeOrigin::hash): Deleted.
        (JSC::CodeOrigin::operator==): Deleted.
        (JSC::CodeOrigin::codeOriginOwner): Deleted.
        (JSC::CodeOriginHash::hash): Deleted.
        (JSC::CodeOriginHash::equal): Deleted.
        (JSC::CodeOriginApproximateHash::hash): Deleted.
        (JSC::CodeOriginApproximateHash::equal): Deleted.
        * bytecode/InlineCallFrameSet.cpp:
        * dfg/DFGCommonData.cpp:
        * dfg/DFGOSRExitBase.cpp:
        * dfg/DFGVariableEventStream.cpp:
        * ftl/FTLOperations.cpp:
        * interpreter/CallFrame.cpp:
        * interpreter/StackVisitor.cpp:
        * jit/AssemblyHelpers.h:
        * profiler/ProfilerOriginStack.cpp:
        * runtime/ClonedArguments.cpp:

2015-09-14  Basile Clement  <basile_clement@apple.com>

        [ES6] Implement tail calls in the LLInt and Baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=148661

        Reviewed by Filip Pizlo.

        This patch introduces two new opcodes, op_tail_call and
        op_tail_call_varargs, to perform tail calls, and implements them in the
        LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
        now. They are currently implemented by sliding the call frame and
        masquerading as our own caller right before performing an actual call.

        This required to change the operationLink family of operation to return
        a SlowPathReturnType instead of a char* in order to distinguish between
        exception cases and actual call cases. We introduce a new FrameAction
        enum that indicates whether to reuse (non-exceptional tail call) or
        keep the current call frame (non-tail call, and exceptional cases).

        This is also a semantics change, since the Function.caller property is
        now leaking tail calls. Since tail calls are only used in strict mode,
        which poisons this property, the only way of seeing this semantics
        change is when a sloppy function calls a strict function that then
        tail-calls a sloppy function. Previously, the second sloppy function's
        caller would have been the strict function (i.e. raises a TypeError
        when the .caller attribute is accessed), while it is now the first
        sloppy function. Tests have been updated to reflect that.

        This also changes the assumptions we make about call frames. In order
        to be relatively efficient, we want to be able to compute the frame
        size based only on the argument count, which was not possible
        previously. To enable this, we now enforce at the bytecode generator,
        DFG and FTL level that any space reserved for a call frame is
        stack-aligned, which allows to easily compute its size when performing
        a tail call. In all the "special call cases" (calls from native code,
        inlined cache calls, etc.), we are starting the frame at the current
        stack pointer and thus will always have a stack-aligned frame size.

        Finally, this patch adds a couple of tests to check that tail calls run
        in constant stack space, as well as tests checking that tail calls are
        recognized correctly. Those tests use the handy aforementioned leaking
        of tail calls through Function.caller to detect tail calls. 

        Given that this patch only implements tail calls for the LLInt and
        Baseline JIT, tail calls are disabled by default.  Until changes are
        landed for all tiers, tail call testing and use requires the
        --enableTailCalls=true or equivalent.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Call::Call):
        (JSC::AbstractMacroAssembler::repatchNearCall):
        (JSC::AbstractMacroAssembler::repatchCompact):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationNearCall::CodeLocationNearCall):
        (JSC::CodeLocationNearCall::callMode):
        (JSC::CodeLocationCommon::callAtOffset):
        (JSC::CodeLocationCommon::nearCallAtOffset):
        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::locationOfNearCall):
        (JSC::LinkBuffer::locationOf):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::nearCall):
        (JSC::MacroAssemblerARM::nearTailCall):
        (JSC::MacroAssemblerARM::call):
        (JSC::MacroAssemblerARM::linkCall):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearCall):
        (JSC::MacroAssemblerARM64::nearTailCall):
        (JSC::MacroAssemblerARM64::ret):
        (JSC::MacroAssemblerARM64::linkCall):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::nearCall):
        (JSC::MacroAssemblerARMv7::nearTailCall):
        (JSC::MacroAssemblerARMv7::call):
        (JSC::MacroAssemblerARMv7::linkCall):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::nearCall):
        (JSC::MacroAssemblerMIPS::nearTailCall):
        (JSC::MacroAssemblerMIPS::call):
        (JSC::MacroAssemblerMIPS::linkCall):
        (JSC::MacroAssemblerMIPS::repatchCall):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::call):
        (JSC::MacroAssemblerSH4::nearTailCall):
        (JSC::MacroAssemblerSH4::nearCall):
        (JSC::MacroAssemblerSH4::linkCall):
        (JSC::MacroAssemblerSH4::repatchCall):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::linkCall):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::breakpoint):
        (JSC::MacroAssemblerX86Common::nearTailCall):
        (JSC::MacroAssemblerX86Common::nearCall):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::linkCall):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        (JSC::CallLinkInfo::isVarargsCallType):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::specializationKind):
        (JSC::CallLinkInfo::callModeFor):
        (JSC::CallLinkInfo::callMode):
        (JSC::CallLinkInfo::isTailCall):
        (JSC::CallLinkInfo::isVarargs):
        (JSC::CallLinkInfo::registerPreservationMode):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CallMode.cpp: Added.
        (WTF::printInternal):
        * bytecode/CallMode.h: Added.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::LabelNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isCallBytecode):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::emitNakedTailCall):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/Repatch.cpp:
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::arityFixupGenerator):
        (JSC::unreachableGenerator):
        (JSC::baselineGetterReturnThunkGenerator):
        * jit/ThunkGenerators.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        (JSC::CommonSlowPaths::opIn):
        * runtime/Options.h:
        * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
        (shouldThrow):
        (sloppyCountdown.even):
        (sloppyCountdown.odd):
        (strictCountdown.even):
        (strictCountdown.odd):
        (strictCountdown):
        (odd):
        (even):
        * tests/stress/tail-call-no-stack-overflow.js: Added.
        (shouldThrow):
        (strictLoop):
        (strictLoopArityFixup1):
        (strictLoopArityFixup2):
        * tests/stress/tail-call-recognize.js: Added.
        (callerMustBeRun):
        (callerMustBeStrict):
        (runTests):
        * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
        (shouldThrow):
        (strictLoop):
        * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
        (tail):
        (obj.method):
        (obj.get fromNative):
        (getThis):

2015-09-10  Michael Saboff  <msaboff@apple.com>

        Add support for Callee-Saves registers
        https://bugs.webkit.org/show_bug.cgi?id=148666

        Reviewed by Filip Pizlo.

        We save platform callee save registers right below the call frame header,
        in the location(s) starting with VirtualRegister 0.  This local space is
        allocated in the bytecode compiler.  This space is the maximum space
        needed for the callee registers that the LLInt and baseline JIT use,
        rounded up to a stack aligned number of VirtualRegisters.
        The LLInt explicitly saves and restores the registers in the macros
        preserveCalleeSavesUsedByLLInt and restoreCalleeSavesUsedByLLInt.
        The JITs saves and restores callee saves registers by what registers
        are included in m_calleeSaveRegisters in the code block.

        Added handling of callee save register restoration to exception handling.
        The basic flow is when an exception is thrown or one is recognized to
        have been generated in C++ code, we save the current state of all
        callee save registers to VM::calleeSaveRegistersBuffer.  As we unwind
        looking for the corresponding catch, we copy the callee saves from call 
        frames to the same VM::calleeSaveRegistersBuffer.  This is done for all
        call frames on the stack up to but not including the call frame that has
        the corresponding catch block.  When we process the catch, we restore
        the callee save registers with the contents of VM::calleeSaveRegistersBuffer.
        If there isn't a catch, then handleUncaughtException will restore callee
        saves before it returns back to the calling C++.

        Eliminated callee saves registers as free registers for various thunk
        generators as the callee saves may not have been saved by the function
        calling the thunk.

        Added code to transition callee saves from one VM's format to the another
        as part of OSR entry and OSR exit.

        Cleaned up the static RegisterSet's including adding one for LLInt and 
        baseline JIT callee saves and one to be used to allocate local registers
        not including the callee saves or other special registers.

        Moved ftl/FTLRegisterAtOffset.{cpp,h} to jit/RegisterAtOffset.{cpp,h}.
        Factored out the vector of RegisterAtOffsets in ftl/FTLUnwindInfo.{cpp,h}
        into a new class in jit/RegisterAtOffsetList.{cpp,h}.
        Eliminted UnwindInfo and changed UnwindInfo::parse() into a standalone
        function named parseUnwindInfo.  That standalone function now returns
        the callee saves RegisterAtOffsetList.  This is stored in the CodeBlock
        and used instead of UnwindInfo.

        Turned off register preservation thunks for outgoing calls from FTL
        generated code.  THey'll be removed in a subsequent patch.

        Changed specialized thinks to save and restore the contents of
        tagTypeNumberRegister and tagMaskRegister as they can be called by FTL
        compiled functions.  We materialize those tag registers for the thunk's
        use and then restore the prior contents on function exit.

        Also removed the arity check fail return thunk since it is now the
        caller's responsibility to restore the stack pointer.

        Removed saving of callee save registers and materialization of special
        tag registers for 64 bit platforms from vmEntryToJavaScript and
        vmEntryToNative.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLJITCode.h:
        * ftl/FTLRegisterAtOffset.cpp: Removed.
        * ftl/FTLRegisterAtOffset.h: Removed.
        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::parseUnwindInfo):
        (JSC::FTL::UnwindInfo::UnwindInfo): Deleted.
        (JSC::FTL::UnwindInfo::~UnwindInfo): Deleted.
        (JSC::FTL::UnwindInfo::parse): Deleted.
        (JSC::FTL::UnwindInfo::dump): Deleted.
        (JSC::FTL::UnwindInfo::find): Deleted.
        (JSC::FTL::UnwindInfo::indexOf): Deleted.
        * ftl/FTLUnwindInfo.h:
        (JSC::RegisterAtOffset::dump):
        * jit/RegisterAtOffset.cpp: Added.
        * jit/RegisterAtOffset.h: Added.
        (JSC::RegisterAtOffset::RegisterAtOffset):
        (JSC::RegisterAtOffset::operator!):
        (JSC::RegisterAtOffset::reg):
        (JSC::RegisterAtOffset::offset):
        (JSC::RegisterAtOffset::offsetAsIndex):
        (JSC::RegisterAtOffset::operator==):
        (JSC::RegisterAtOffset::operator<):
        (JSC::RegisterAtOffset::getReg):
        * jit/RegisterAtOffsetList.cpp: Added.
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        (JSC::RegisterAtOffsetList::sort):
        (JSC::RegisterAtOffsetList::dump):
        (JSC::RegisterAtOffsetList::find):
        (JSC::RegisterAtOffsetList::indexOf):
        * jit/RegisterAtOffsetList.h: Added.
        (JSC::RegisterAtOffsetList::clear):
        (JSC::RegisterAtOffsetList::size):
        (JSC::RegisterAtOffsetList::at):
        (JSC::RegisterAtOffsetList::append):
        Move and refactored use of FTLRegisterAtOffset to RegisterAtOffset.
        Added RegisterAtOffset and RegisterAtOffsetList to build configurations.
        Remove FTLRegisterAtOffset files.

        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setUpCallFromFTL):
        Turned off FTL register preservation thunks.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::setCalleeSaveRegisters):
        (JSC::roundCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
        (JSC::CodeBlock::calleeSaveRegisters):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::optimizeAfterWarmUp):
        (JSC::CodeBlock::numberOfDFGCompiles):
        Methods to manage a set of callee save registers.  Also to allocate the appropriate
        number of VirtualRegisters for callee saves.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::allocateCalleeSaveSpace):
        * bytecompiler/BytecodeGenerator.h:
        Allocate the appropriate number of VirtualRegisters for callee saves needed by LLInt or baseline JIT.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        (JSC::DFG::JITCompiler::compileBody):
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::usedRegisters):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::fixFunctionBasedOnStackMaps):
        (JSC::FTL::compile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::osrExitGenerationThunkGenerator):
        * jit/ArityCheckFailReturnThunks.cpp: Removed.
        * jit/ArityCheckFailReturnThunks.h: Removed.
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emit_op_ret):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        * jit/ThunkGenerators.cpp:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::arityFixupGenerator):
        * runtime/CommonSlowPaths.cpp:
        (JSC::setupArityCheckData):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        Emit code to save and restore callee save registers and materialize tagTypeNumberRegister
        and tagMaskRegister.
        Handle callee saves when tiering up.
        Copy callee saves register contents to VM::calleeSaveRegistersBuffer at beginning of
        exception processing.
        Process callee save registers in frames when unwinding from an exception.
        Restore callee saves register contents from VM::calleeSaveRegistersBuffer on catch.
        Use appropriate register set to make sure we don't allocate a callee save register when
        compiling a thunk.
        Helper to populate tagTypeNumberRegister and tagMaskRegister with the appropriate
        constants.
        Removed arity fixup return thunks.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        Restore callee saves from the DFG and save the appropriate ones for the baseline JIT.
        Materialize the tag registers on 64 bit platforms.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
        (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
        (JSC::AssemblyHelpers::emitSaveCalleeSaves):
        (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
        New helpers to save and restore callee saves as well as materialize the tag registers
        contents.

        * jit/FPRInfo.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toRegister):
        Updated to include FP callee save registers.  Added number of callee saves registers and
        cleanup register aliases that collide with callee save registers.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        Uses new stubUnavailableRegisters register set to limit what registers are available for 
        temporaries.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::stubUnavailableRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        (JSC::RegisterSet::dfgCalleeSaveRegisters):
        (JSC::RegisterSet::ftlCalleeSaveRegisters):
        * jit/RegisterSet.h:
        New register sets with the callee saves used by various tiers as well as one listing registers
        not availble to stub code.

        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::loadDoubleArgument):
        (JSC::SpecializedThunkJIT::returnJSValue):
        (JSC::SpecializedThunkJIT::returnDouble):
        (JSC::SpecializedThunkJIT::returnInt32):
        (JSC::SpecializedThunkJIT::returnJSCell):
        (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
        (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters):
        (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        Changed to save and restore existing tag register contents as the may contain other values.
        After saving the existing values, we materialize the tag constants.

        * jit/TempRegisterSet.h:
        (JSC::TempRegisterSet::getFPRByIndex):
        (JSC::TempRegisterSet::getFreeFPR):
        (JSC::TempRegisterSet::setByIndex):
        * offlineasm/arm64.rb:
        * offlineasm/registers.rb:
        Added methods for floating point registers to support callee save FP registers.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_mod):
        Removed unnecessary #if CPU(X86_64) check to this 32 bit only file.

        * offlineasm/x86.rb:
        Fixed Windows callee saves naming.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::calleeSaveRegistersBufferOffset):
        (JSC::VM::getAllCalleeSaveRegistersMap):
        Provide a RegisterSaveMap that has all registers that might be saved.  Added a callee save buffer to be
        used for OSR exit and for exception processing in a future patch.

2015-09-03  Basile Clement  <basile_clement@apple.com> and Michael Saboff  <msaboff@apple.com>

        Clean up register naming
        https://bugs.webkit.org/show_bug.cgi?id=148658

        Reviewed by Geoffrey Garen.

        This changes register naming conventions in the llint and baseline JIT
        in order to use as few (native) callee-save registers as possible on
        64-bits platforms. It also introduces significant changes in the way
        registers names are defined in the LLint and baseline JIT in order to
        enable a simpler convention about which registers can be aliased. That
        convention is valid across all architecture, and described in
        llint/LowLevelInterpreter.asm.

        Callee save registers are now called out regCS<n> (in the JIT) or
        csr<n> (in the LLInt) with a common numbering across all tiers. Some
        registers are unused in some tiers.

        As a part of this change, rdi was removed from the list of temporary
        registers for X86-64 Windows as it is a callee saves register. This
        reduced the number of temporary registers for X86-64 Windows.

        This is in preparation for properly handling callee save register
        preservation and restoration.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/FPRInfo.h:
        (JSC::FPRInfo::toRegister):
        (JSC::FPRInfo::toIndex):
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toIndex):
        (JSC::GPRInfo::toRegister):
        (JSC::GPRInfo::debugName): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_mod):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_new_object):
        * jit/RegisterPreservationWrapperGenerator.cpp:
        (JSC::generateRegisterPreservationWrapper):
        (JSC::generateRegisterRestoration):
        * jit/ThunkGenerators.cpp:
        (JSC::arityFixupGenerator):
        (JSC::nativeForGenerator): Deleted.
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm.rb:
        * offlineasm/arm64.rb:
        * offlineasm/cloop.rb:
        * offlineasm/mips.rb:
        * offlineasm/registers.rb:
        * offlineasm/sh4.rb:
        * offlineasm/x86.rb:

2015-09-03  Basile Clement  <basile_clement@apple.com>

        [ES6] Recognize calls in tail position
        https://bugs.webkit.org/show_bug.cgi?id=148665

        Reviewed by Saam Barati.

        This patch adds the capability for the bytecode generator to recognize
        and dispatch tail calls, as per ES6 spec:
        http://www.ecma-international.org/ecma-262/6.0/#sec-isintailposition

        This does not change the generated bytecode, but merely provides the
        hook for generating tail calls in subsequent patches toward
        https://bugs.webkit.org/show_bug.cgi?id=146477

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::emitNodeInTailPosition):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::LogicalOpNode::emitBytecode):
        (JSC::ConditionalNode::emitBytecode):
        (JSC::CommaNode::emitBytecode):
        (JSC::SourceElements::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        * bytecompiler/SetForScope.h: Added.
        (JSC::SetForScope::SetForScope):
        (JSC::SetForScope::~SetForScope):
        * runtime/Options.h:

2016-06-14  Keith Miller  <keith_miller@apple.com>

        The Array species constructor watchpoints should be created the first time they are needed rather than on creation
        https://bugs.webkit.org/show_bug.cgi?id=158754

        Reviewed by Benjamin Poulain.

        We use adaptive watchpoints for some Array prototype functions to
        ensure that the user has not overridden the value of the
        Array.prototype.constructor or Array[Symbol.species]. This patch
        changes when the Array species constructor watchpoints are
        initialized. Before, those watchpoints would be created when the
        global object is initialized. This had the advantage that it did
        not require validating the constructor and Symbol.species
        properties. On the other hand, it also meant that if the user were
        to reconfigure properties Array.prototype, which would cause the
        structure of the property to become an uncachable dictionary,
        prior to running code that the watchpoints would be
        invalidated. It turns out that JSBench amazon, for instance, does
        reconfigure some of Array.prototype's properties. This patch
        initializes the watchpoints the first time they are needed. Since
        we only initialize once we also flatten the structure of Array and
        Array.prototype.

        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        (JSC::ArrayPrototype::setConstructor): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::speciesWatchpointStatus):
        (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::speciesGetterSetter):
        (JSC::JSGlobalObject::arrayConstructor):
        * tests/stress/array-symbol-species-lazy-watchpoints.js: Added.
        (test):
        (arrayEq):
        (A):

2016-05-04  Filip Pizlo  <fpizlo@apple.com>

        Speed up JSGlobalObject initialization by making some properties lazy
        https://bugs.webkit.org/show_bug.cgi?id=157045

        Reviewed by Keith Miller.
        
        This makes about half of JSGlobalObject's state lazy. There are three categories of
        state in JSGlobalObject:
        
        1) C++ fields in JSGlobalObject.
        2) JS object properties in JSGlobalObject's JSObject superclass.
        3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
        
        State held in JS variables cannot yet be made lazy. That's why this patch only goes
        half-way.
        
        State in JS object properties can be made lazy if we move it to the static property
        hashtable. JSGlobalObject already had one of those. This patch makes static property
        hashtables a lot more powerful, by adding three new kinds of static properties. These
        new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
        
        State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
        lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
        JSGlobalObject and we are adding more all the time. We don't want to require that each
        of these has a getter with an initialization check and a corresponding out-of-line slow
        path that does the initialization. We want this kind of boilerplate to be handled by
        some abstractions.
        
        The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
        only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
        You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
        so it's almost a drop-in replacement.
        
        The key to LazyProperty<Type>'s power is that you can do this:
        
            class Bar {
                ...
                LazyProperty<Foo> m_foo;
            };
            ...
            m_foo.initLater(
                [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
                    init.set(Foo::create(init.vm, init.owner));
                });
        
        This initLater() call requires that you pass a stateless lambda (see WTF changelog for
        the definition). Miraculously, this initLater() call is guaranteed to compile to a store
        of a pointer constant to m_foo, as in:
        
            movabsq 0xBLAH, %rax
            movq %rax, &m_foo
        
        This magical pointer constant points to a callback that was generated by the template
        instantiation of initLater(). That callback knows to call your stateless lambda, but
        also does some other bookkeeping: it makes sure that you indeed initialized the property
        inside the callback and it manages recursive initializations. It's totally legal to call
        m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
        m_foo.get() will return null. This is an excellent escape hatch if we ever find
        ourselves in a dependency cycle. I added this feature because I already had to create a
        dependency cycle.
        
        Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
        to get this right. The DFG thread cannot initialize those fields, so it has to make sure
        that it does conservative things. But for some nodes this could mean adding a lot of new
        logic, like NewTypedArray, which currently is written in such a way that it assumes that
        we always have the typed array structure. Currently we take a two-fold approach: for
        typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
        initialized, and for everything else we don't make the properties lazy if the DFG needs
        them. As we optimize this further we might need to teach the DFG to handle more lazy
        properties. I tried to do this for RegExp but found it to be very confusing. With typed
        arrays I got lucky.
        
        There is also a somewhat more powerful construct called LazyClassStructure. We often
        need to keep around the structure of some standard JS class, like Date. We also need to
        make sure that the constructor ends up in the global object's property table. And we
        often need to keep the original value of the constructor for ourselves. In this case, we
        want to make sure that the creation of the structure-prototype-constructor constellation
        is atomic. We don't want code to start looking at the structure if it points to a
        prototype that doesn't have its "constructor" property set yet, for example.
        LazyClassStructure solves this by abstracting that whole initialization. You provide the
        callback that allocates everything, since we are super inconsistent about the way we
        initialize things, but LazyClassStructure establishes the workflow and helps you not
        mess up.
        
        Finally, the new static hashtable attributes allow for all of this to work with the JS
        property table:
        
        PropertyCallback: if you use this attribute, the second column in the table should be
        the name of a function to call to initialize this property. This is useful for things
        like the Math property. The Math object turns out to be very expensive to allocate.
        Delaying its allocation is super easy with the PropertyCallback attribute.
        
        CellProperty: with this attribute the second column should be a C++ field name like
        JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
        this property, and when it needs to be initialized, Lookup will assume you have a
        LazyProperty<JSCell> and call its get() method. It will initialize the property to
        whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
        LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
        call whatever callback function pointer is encoded in the property and it does not need
        to know anything about what type that callback will instantiate.
        
        ClassStructure: with this attribute the second column should be a C++ field name. The
        static hashtable will initialize the property by treating the field as a
        LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
        initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
        the property in question will already be set. By convention, we have LazyClassStructure
        initialize the property with a pointer to the constructor, since that's how all of our
        classes work: "globalObject.Date" points to the DateConstructor.
        
        This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
        calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
        
        Rolling this back in after fixing the function pointer alignment issue. The last version
        relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
        especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
        instruction set. This version adds an extra indirection, so that
        LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
        a pointer is guaranteed to be at least 4-byte aligned.

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::create):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::impl):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::create):
        (JSC::DebuggerScope::DebuggerScope):
        * debugger/DebuggerScope.h:
        (JSC::DebuggerScope::jsScope):
        (JSC::DebuggerScope::create): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::calculatedDisplayName):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::JSBoundSlotBaseFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::retrieveCallerFunction):
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):
        (JSC::createJSONProperty):
        (JSC::createMathProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::toThis):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::createThrowTypeError): Deleted.
        (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectConstructor):
        (JSC::JSGlobalObject::promiseConstructor):
        (JSC::JSGlobalObject::internalPromiseConstructor):
        (JSC::JSGlobalObject::evalErrorConstructor):
        (JSC::JSGlobalObject::rangeErrorConstructor):
        (JSC::JSGlobalObject::referenceErrorConstructor):
        (JSC::JSGlobalObject::syntaxErrorConstructor):
        (JSC::JSGlobalObject::typeErrorConstructor):
        (JSC::JSGlobalObject::URIErrorConstructor):
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::nullSetterFunction):
        (JSC::JSGlobalObject::callFunction):
        (JSC::JSGlobalObject::applyFunction):
        (JSC::JSGlobalObject::definePropertyFunction):
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseCapabilityFunction):
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        (JSC::JSGlobalObject::regExpProtoExecFunction):
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::objectPrototype):
        (JSC::JSGlobalObject::functionPrototype):
        (JSC::JSGlobalObject::arrayPrototype):
        (JSC::JSGlobalObject::booleanPrototype):
        (JSC::JSGlobalObject::stringPrototype):
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::numberPrototype):
        (JSC::JSGlobalObject::datePrototype):
        (JSC::JSGlobalObject::regExpPrototype):
        (JSC::JSGlobalObject::errorPrototype):
        (JSC::JSGlobalObject::iteratorPrototype):
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::debuggerScopeStructure):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::moduleEnvironmentStructure):
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::JSGlobalObject::booleanObjectStructure):
        (JSC::JSGlobalObject::callbackConstructorStructure):
        (JSC::JSGlobalObject::callbackFunctionStructure):
        (JSC::JSGlobalObject::callbackObjectStructure):
        (JSC::JSGlobalObject::propertyNameIteratorStructure):
        (JSC::JSGlobalObject::objcCallbackFunctionStructure):
        (JSC::JSGlobalObject::objcWrapperObjectStructure):
        (JSC::JSGlobalObject::dateStructure):
        (JSC::JSGlobalObject::nullPrototypeObjectStructure):
        (JSC::JSGlobalObject::errorStructure):
        (JSC::JSGlobalObject::calleeStructure):
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        (JSC::JSGlobalObject::numberObjectStructure):
        (JSC::JSGlobalObject::privateNameStructure):
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpStructure):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        (JSC::JSGlobalObject::setStructure):
        (JSC::JSGlobalObject::stringObjectStructure):
        (JSC::JSGlobalObject::symbolObjectStructure):
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::lazyTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructureConcurrently):
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayConstructor):
        (JSC::JSGlobalObject::actualPointerFor):
        (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::visitChildren):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::create): Deleted.
        (JSC::JSWithScope::createStructure): Deleted.
        (JSC::JSWithScope::JSWithScope): Deleted.
        * runtime/LazyClassStructure.cpp: Added.
        (JSC::LazyClassStructure::Initializer::Initializer):
        (JSC::LazyClassStructure::Initializer::setPrototype):
        (JSC::LazyClassStructure::Initializer::setStructure):
        (JSC::LazyClassStructure::Initializer::setConstructor):
        (JSC::LazyClassStructure::visit):
        (JSC::LazyClassStructure::dump):
        * runtime/LazyClassStructure.h: Added.
        (JSC::LazyClassStructure::LazyClassStructure):
        (JSC::LazyClassStructure::get):
        (JSC::LazyClassStructure::prototype):
        (JSC::LazyClassStructure::constructor):
        (JSC::LazyClassStructure::getConcurrently):
        (JSC::LazyClassStructure::prototypeConcurrently):
        (JSC::LazyClassStructure::constructorConcurrently):
        * runtime/LazyClassStructureInlines.h: Added.
        (JSC::LazyClassStructure::initLater):
        * runtime/LazyProperty.h: Added.
        (JSC::LazyProperty::Initializer::Initializer):
        (JSC::LazyProperty::LazyProperty):
        (JSC::LazyProperty::get):
        (JSC::LazyProperty::getConcurrently):
        * runtime/LazyPropertyInlines.h: Added.
        (JSC::ElementType>::Initializer::set):
        (JSC::ElementType>::initLater):
        (JSC::ElementType>::setMayBeNull):
        (JSC::ElementType>::set):
        (JSC::ElementType>::visit):
        (JSC::ElementType>::dump):
        (JSC::ElementType>::callFunc):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::function):
        (JSC::HashTableValue::functionLength):
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::HashTableValue::constantInteger):
        (JSC::HashTableValue::lexerValue):
        (JSC::HashTableValue::lazyCellPropertyOffset):
        (JSC::HashTableValue::lazyClassStructureOffset):
        (JSC::HashTableValue::lazyPropertyCallback):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::putEntry):
        (JSC::reifyStaticProperty):
        * runtime/PropertySlot.h:
        * runtime/TypedArrayType.h:

2016-02-10  Keith Miller  <keith_miller@apple.com>

        Symbol.species accessors on builtin constructors should be configurable
        https://bugs.webkit.org/show_bug.cgi?id=154097

        Reviewed by Benjamin Poulain.

        We did not have the Symbol.species accessors on our builtin constructors
        marked as configurable. This does not accurately follow the ES6 spec as
        the ES6 spec states that all default accessors on builtins should be
        configurable. This means that we need an additional watchpoint on
        ArrayConstructor to make sure that no users re-configures Symbol.species.

        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::ArrayPrototype::setConstructor):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties):
        (JSC::ArrayPrototype::didChangeConstructorProperty): Deleted.
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * tests/stress/array-species-config-array-constructor.js: Added.
        (A):
        * tests/stress/symbol-species.js:
        (testSymbolSpeciesOnConstructor):

2016-01-29  Keith Miller  <keith_miller@apple.com>

        Array.prototype native functions should use Symbol.species to construct the result
        https://bugs.webkit.org/show_bug.cgi?id=153660

        Reviewed by Saam Barati.

        This patch adds support for Symbol.species in the Array.prototype native functions.
        We make an optimization to avoid regressions on some benchmarks by using an
        adaptive watchpoint to check if Array.prototype.constructor is ever changed.

        * runtime/ArrayPrototype.cpp:
        (JSC::putLength):
        (JSC::setLength):
        (JSC::speciesConstructArray):
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::ArrayPrototype::setConstructor):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::didChangeConstructorProperty):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/es6.yaml:
        * tests/stress/array-species-functions.js: Added.
        (Symbol.species):
        (funcThrows):
        (test.species):
        (test):

2015-11-10  Keith Miller  <keith_miller@apple.com>

        Regression(r191815): 5.3% regression on Dromaeo JS Library Benchmark
        https://bugs.webkit.org/show_bug.cgi?id=150945

        Reviewed by Filip Pizlo.

        This patch fixes a performance regression introduced by r191815. Before adding Symbol.toStringTag
        we would cache the value of Object.prototype.toString() in the rareData of the structure.
        In order to cache the result of Object.prototype.toString() we now need to ensure that the
        value stored in Symbol.toStringTag is a known constant. Thus, in order to ensure the stored Symbol.toStringTag
        value remains constant adaptive inferred value watchpoints have been re-factored to be generalizable and
        a new version that clears the toString value cache when fired has been added.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setObjectToStringValue):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::StructureRareData):
        (JSC::StructureRareData::setObjectToStringValue):
        (JSC::StructureRareData::clearObjectToStringValue):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::setObjectToStringValue): Deleted.
        * tests/stress/symbol-tostringtag-watchpoints.js: Added.
        (Base):

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setObjectToStringValue):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::StructureRareData):
        (JSC::StructureRareData::setObjectToStringValue):
        (JSC::StructureRareData::clearObjectToStringValue):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::setObjectToStringValue): Deleted.
        * tests/stress/symbol-tostringtag-watchpoints.js: Added.
        (Base):

2015-11-01  Alexey Proskuryakov  <ap@apple.com>

        [ES6] Add support for toStringTag
        https://bugs.webkit.org/show_bug.cgi?id=150696

        Re-landing, as this wasn't the culprit.

        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        (JSC::JSArrayBufferPrototype::create):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::create):
        (JSC::JSDataViewPrototype::finishCreation):
        (JSC::JSDataViewPrototype::createStructure):
        * runtime/JSDataViewPrototype.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        (JSC::JSPromisePrototype::getOwnPropertySlot):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncValues):
        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::SmallStrings):
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::visitStrongReferences):
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::typeString):
        (JSC::SmallStrings::objectStringStart):
        (JSC::SmallStrings::nullObjectString):
        (JSC::SmallStrings::undefinedObjectString):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMapData):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        (JSC::getWeakMapData):
        * tests/es6.yaml:
        * tests/modules/namespace.js:
        * tests/stress/symbol-tostringtag.js: Copied from Source/JavaScriptCore/tests/stress/symbol-tostringtag.js.

2015-07-31  Filip Pizlo  <fpizlo@apple.com>

        DFG should have adaptive structure watchpoints
        https://bugs.webkit.org/show_bug.cgi?id=146929

        Reviewed by Geoffrey Garen.

        Before this change, if you wanted to efficiently validate whether an object has (or doesn't have) a
        property, you'd check that the object still has the structure that you first saw the object have. We
        optimized this a bit with transition watchpoints on the structure, which sometimes allowed us to
        elide the structure check.

        But this approach fails when that object frequently has new properties added to it. This would
        change the structure and fire the transition watchpoint, so the code we emitted would be invalid and
        we'd have to recompile either the IC or an entire code block.

        This change introduces a new concept: an object property condition. This value describes some
        condition involving a property on some object. There are four kinds: presence, absence,
        absence-of-setter, and equivalence. For example, a presence condition says that we expect that the
        object has some property at some offset with some attributes. This allows us to implement a new kind
        of watchpoint, which knows about the object property condition that it's being used to enforce. If
        the watchpoint fires because of a structure transition, the watchpoint may simply reinstall itself
        on the new structure.

        Object property conditions are used on the prototype chain of PutById transitions, GetById misses,
        and prototype accesses. They are also used for any DFG accesses to object constants, including
        global property accesses.

        Mostly because of the effect on global property access, this is a 9% speed-up on Kraken. It's
        neutral on most other things. It's a 68x speed-up on a microbenchmark that illustrates the prototype
        chain situation. It's also a small speed-up on getter-richards.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdCacheStatus):
        * bytecode/CodeBlockJettisoningWatchpoint.cpp:
        (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/ComplexGetStatus.h:
        (JSC::ComplexGetStatus::ComplexGetStatus):
        (JSC::ComplexGetStatus::takesSlowPath):
        (JSC::ComplexGetStatus::kind):
        (JSC::ComplexGetStatus::offset):
        (JSC::ComplexGetStatus::conditionSet):
        (JSC::ComplexGetStatus::attributes): Deleted.
        (JSC::ComplexGetStatus::specificValue): Deleted.
        (JSC::ComplexGetStatus::chain): Deleted.
        * bytecode/ConstantStructureCheck.cpp: Removed.
        * bytecode/ConstantStructureCheck.h: Removed.
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfo):
        * bytecode/GetByIdVariant.cpp:
        (JSC::GetByIdVariant::GetByIdVariant):
        (JSC::GetByIdVariant::~GetByIdVariant):
        (JSC::GetByIdVariant::operator=):
        (JSC::GetByIdVariant::attemptToMerge):
        (JSC::GetByIdVariant::dumpInContext):
        (JSC::GetByIdVariant::baseStructure): Deleted.
        * bytecode/GetByIdVariant.h:
        (JSC::GetByIdVariant::operator!):
        (JSC::GetByIdVariant::structureSet):
        (JSC::GetByIdVariant::conditionSet):
        (JSC::GetByIdVariant::offset):
        (JSC::GetByIdVariant::callLinkStatus):
        (JSC::GetByIdVariant::constantChecks): Deleted.
        (JSC::GetByIdVariant::alternateBase): Deleted.
        * bytecode/ObjectPropertyCondition.cpp: Added.
        (JSC::ObjectPropertyCondition::dumpInContext):
        (JSC::ObjectPropertyCondition::dump):
        (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
        (JSC::ObjectPropertyCondition::validityRequiresImpurePropertyWatchpoint):
        (JSC::ObjectPropertyCondition::isStillValid):
        (JSC::ObjectPropertyCondition::structureEnsuresValidity):
        (JSC::ObjectPropertyCondition::isWatchableAssumingImpurePropertyWatchpoint):
        (JSC::ObjectPropertyCondition::isWatchable):
        (JSC::ObjectPropertyCondition::isStillLive):
        (JSC::ObjectPropertyCondition::validateReferences):
        (JSC::ObjectPropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
        * bytecode/ObjectPropertyCondition.h: Added.
        (JSC::ObjectPropertyCondition::ObjectPropertyCondition):
        (JSC::ObjectPropertyCondition::presenceWithoutBarrier):
        (JSC::ObjectPropertyCondition::presence):
        (JSC::ObjectPropertyCondition::absenceWithoutBarrier):
        (JSC::ObjectPropertyCondition::absence):
        (JSC::ObjectPropertyCondition::absenceOfSetterWithoutBarrier):
        (JSC::ObjectPropertyCondition::absenceOfSetter):
        (JSC::ObjectPropertyCondition::equivalenceWithoutBarrier):
        (JSC::ObjectPropertyCondition::equivalence):
        (JSC::ObjectPropertyCondition::operator!):
        (JSC::ObjectPropertyCondition::object):
        (JSC::ObjectPropertyCondition::condition):
        (JSC::ObjectPropertyCondition::kind):
        (JSC::ObjectPropertyCondition::uid):
        (JSC::ObjectPropertyCondition::hasOffset):
        (JSC::ObjectPropertyCondition::offset):
        (JSC::ObjectPropertyCondition::hasAttributes):
        (JSC::ObjectPropertyCondition::attributes):
        (JSC::ObjectPropertyCondition::hasPrototype):
        (JSC::ObjectPropertyCondition::prototype):
        (JSC::ObjectPropertyCondition::hasRequiredValue):
        (JSC::ObjectPropertyCondition::requiredValue):
        (JSC::ObjectPropertyCondition::hash):
        (JSC::ObjectPropertyCondition::operator==):
        (JSC::ObjectPropertyCondition::isHashTableDeletedValue):
        (JSC::ObjectPropertyCondition::isCompatibleWith):
        (JSC::ObjectPropertyCondition::watchingRequiresStructureTransitionWatchpoint):
        (JSC::ObjectPropertyCondition::watchingRequiresReplacementWatchpoint):
        (JSC::ObjectPropertyCondition::isValidValueForPresence):
        (JSC::ObjectPropertyConditionHash::hash):
        (JSC::ObjectPropertyConditionHash::equal):
        * bytecode/ObjectPropertyConditionSet.cpp: Added.
        (JSC::ObjectPropertyConditionSet::forObject):
        (JSC::ObjectPropertyConditionSet::forConditionKind):
        (JSC::ObjectPropertyConditionSet::numberOfConditionsWithKind):
        (JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition):
        (JSC::ObjectPropertyConditionSet::slotBaseCondition):
        (JSC::ObjectPropertyConditionSet::mergedWith):
        (JSC::ObjectPropertyConditionSet::structuresEnsureValidity):
        (JSC::ObjectPropertyConditionSet::structuresEnsureValidityAssumingImpurePropertyWatchpoint):
        (JSC::ObjectPropertyConditionSet::needImpurePropertyWatchpoint):
        (JSC::ObjectPropertyConditionSet::areStillLive):
        (JSC::ObjectPropertyConditionSet::dumpInContext):
        (JSC::ObjectPropertyConditionSet::dump):
        (JSC::generateConditionsForPropertyMiss):
        (JSC::generateConditionsForPropertySetterMiss):
        (JSC::generateConditionsForPrototypePropertyHit):
        (JSC::generateConditionsForPrototypePropertyHitCustom):
        (JSC::generateConditionsForPropertySetterMissConcurrently):
        * bytecode/ObjectPropertyConditionSet.h: Added.
        (JSC::ObjectPropertyConditionSet::ObjectPropertyConditionSet):
        (JSC::ObjectPropertyConditionSet::invalid):
        (JSC::ObjectPropertyConditionSet::nonEmpty):
        (JSC::ObjectPropertyConditionSet::isValid):
        (JSC::ObjectPropertyConditionSet::isEmpty):
        (JSC::ObjectPropertyConditionSet::begin):
        (JSC::ObjectPropertyConditionSet::end):
        (JSC::ObjectPropertyConditionSet::releaseRawPointer):
        (JSC::ObjectPropertyConditionSet::adoptRawPointer):
        (JSC::ObjectPropertyConditionSet::fromRawPointer):
        (JSC::ObjectPropertyConditionSet::Data::Data):
        * bytecode/PolymorphicGetByIdList.cpp:
        (JSC::GetByIdAccess::GetByIdAccess):
        (JSC::GetByIdAccess::~GetByIdAccess):
        (JSC::GetByIdAccess::visitWeak):
        * bytecode/PolymorphicGetByIdList.h:
        (JSC::GetByIdAccess::GetByIdAccess):
        (JSC::GetByIdAccess::structure):
        (JSC::GetByIdAccess::conditionSet):
        (JSC::GetByIdAccess::stubRoutine):
        (JSC::GetByIdAccess::chain): Deleted.
        (JSC::GetByIdAccess::chainCount): Deleted.
        * bytecode/PolymorphicPutByIdList.cpp:
        (JSC::PutByIdAccess::fromStructureStubInfo):
        (JSC::PutByIdAccess::visitWeak):
        * bytecode/PolymorphicPutByIdList.h:
        (JSC::PutByIdAccess::PutByIdAccess):
        (JSC::PutByIdAccess::transition):
        (JSC::PutByIdAccess::setter):
        (JSC::PutByIdAccess::newStructure):
        (JSC::PutByIdAccess::conditionSet):
        (JSC::PutByIdAccess::stubRoutine):
        (JSC::PutByIdAccess::chain): Deleted.
        (JSC::PutByIdAccess::chainCount): Deleted.
        * bytecode/PropertyCondition.cpp: Added.
        (JSC::PropertyCondition::dumpInContext):
        (JSC::PropertyCondition::dump):
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
        (JSC::PropertyCondition::validityRequiresImpurePropertyWatchpoint):
        (JSC::PropertyCondition::isStillValid):
        (JSC::PropertyCondition::isWatchableWhenValid):
        (JSC::PropertyCondition::isWatchableAssumingImpurePropertyWatchpoint):
        (JSC::PropertyCondition::isWatchable):
        (JSC::PropertyCondition::isStillLive):
        (JSC::PropertyCondition::validateReferences):
        (JSC::PropertyCondition::isValidValueForAttributes):
        (JSC::PropertyCondition::isValidValueForPresence):
        (JSC::PropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
        (WTF::printInternal):
        * bytecode/PropertyCondition.h: Added.
        (JSC::PropertyCondition::PropertyCondition):
        (JSC::PropertyCondition::presenceWithoutBarrier):
        (JSC::PropertyCondition::presence):
        (JSC::PropertyCondition::absenceWithoutBarrier):
        (JSC::PropertyCondition::absence):
        (JSC::PropertyCondition::absenceOfSetterWithoutBarrier):
        (JSC::PropertyCondition::absenceOfSetter):
        (JSC::PropertyCondition::equivalenceWithoutBarrier):
        (JSC::PropertyCondition::equivalence):
        (JSC::PropertyCondition::operator!):
        (JSC::PropertyCondition::kind):
        (JSC::PropertyCondition::uid):
        (JSC::PropertyCondition::hasOffset):
        (JSC::PropertyCondition::offset):
        (JSC::PropertyCondition::hasAttributes):
        (JSC::PropertyCondition::attributes):
        (JSC::PropertyCondition::hasPrototype):
        (JSC::PropertyCondition::prototype):
        (JSC::PropertyCondition::hasRequiredValue):
        (JSC::PropertyCondition::requiredValue):
        (JSC::PropertyCondition::hash):
        (JSC::PropertyCondition::operator==):
        (JSC::PropertyCondition::isHashTableDeletedValue):
        (JSC::PropertyCondition::isCompatibleWith):
        (JSC::PropertyCondition::watchingRequiresStructureTransitionWatchpoint):
        (JSC::PropertyCondition::watchingRequiresReplacementWatchpoint):
        (JSC::PropertyConditionHash::hash):
        (JSC::PropertyConditionHash::equal):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::operator=):
        (JSC::PutByIdVariant::transition):
        (JSC::PutByIdVariant::setter):
        (JSC::PutByIdVariant::makesCalls):
        (JSC::PutByIdVariant::attemptToMerge):
        (JSC::PutByIdVariant::attemptToMergeTransitionWithReplace):
        (JSC::PutByIdVariant::dumpInContext):
        (JSC::PutByIdVariant::baseStructure): Deleted.
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::PutByIdVariant):
        (JSC::PutByIdVariant::kind):
        (JSC::PutByIdVariant::structure):
        (JSC::PutByIdVariant::structureSet):
        (JSC::PutByIdVariant::oldStructure):
        (JSC::PutByIdVariant::conditionSet):
        (JSC::PutByIdVariant::offset):
        (JSC::PutByIdVariant::callLinkStatus):
        (JSC::PutByIdVariant::constantChecks): Deleted.
        (JSC::PutByIdVariant::alternateBase): Deleted.
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
        (JSC::StructureStubClearingWatchpoint::push):
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        (JSC::WatchpointsOnStructureStubInfo::~WatchpointsOnStructureStubInfo):
        (JSC::WatchpointsOnStructureStubInfo::addWatchpoint):
        (JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint):
        * bytecode/StructureStubClearingWatchpoint.h:
        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
        (JSC::WatchpointsOnStructureStubInfo::codeBlock):
        (JSC::WatchpointsOnStructureStubInfo::stubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::visitWeakReferences):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::initPutByIdTransition):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::setSeen):
        (JSC::StructureStubInfo::addWatchpoint):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp: Added.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h: Added.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp: Added.
        (JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
        (JSC::DFG::AdaptiveStructureWatchpoint::install):
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * dfg/DFGAdaptiveStructureWatchpoint.h: Added.
        (JSC::DFG::AdaptiveStructureWatchpoint::key):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstantWithStructureCheck):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handlePutByOffset):
        (JSC::DFG::ByteCodeParser::check):
        (JSC::DFG::ByteCodeParser::promoteToConstant):
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::presenceLike):
        (JSC::DFG::ByteCodeParser::checkPresenceLike):
        (JSC::DFG::ByteCodeParser::store):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::emitChecks): Deleted.
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::validateReferences):
        * dfg/DFGCommonData.h:
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
        (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
        (JSC::DFG::ConstantFoldingPhase::addChecks): Deleted.
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
        (JSC::DFG::InferredValueAdaptor::add):
        (JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
        (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
        (JSC::DFG::DesiredWatchpoints::addLazily):
        (JSC::DFG::DesiredWatchpoints::consider):
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid):
        (JSC::DFG::DesiredWatchpoints::dumpInContext):
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::SetPointerAdaptor::add):
        (JSC::DFG::SetPointerAdaptor::hasBeenInvalidated):
        (JSC::DFG::SetPointerAdaptor::dumpInContext):
        (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
        (JSC::DFG::InferredValueAdaptor::dumpInContext):
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated):
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::dumpInContext):
        (JSC::DFG::AdaptiveStructureWatchpointAdaptor::hasBeenInvalidated):
        (JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
        (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
        (JSC::DFG::GenericDesiredWatchpoints::isWatched):
        (JSC::DFG::GenericDesiredWatchpoints::dumpInContext):
        (JSC::DFG::DesiredWatchpoints::isWatched):
        (JSC::DFG::GenericSetAdaptor::add): Deleted.
        (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated): Deleted.
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::addLazily):
        (JSC::DFG::DesiredWeakReferences::contains):
        * dfg/DFGDesiredWeakReferences.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::clearFlagsOnAllNodes):
        (JSC::DFG::Graph::watchCondition):
        (JSC::DFG::Graph::isSafeToLoad):
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::tryGetConstantProperty):
        (JSC::DFG::Graph::visitChildren):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::identifiers):
        (JSC::DFG::Graph::watchpoints):
        * dfg/DFGMultiGetByOffsetData.cpp: Added.
        (JSC::DFG::GetByOffsetMethod::dumpInContext):
        (JSC::DFG::GetByOffsetMethod::dump):
        (JSC::DFG::MultiGetByOffsetCase::dumpInContext):
        (JSC::DFG::MultiGetByOffsetCase::dump):
        (WTF::printInternal):
        * dfg/DFGMultiGetByOffsetData.h: Added.
        (JSC::DFG::GetByOffsetMethod::GetByOffsetMethod):
        (JSC::DFG::GetByOffsetMethod::constant):
        (JSC::DFG::GetByOffsetMethod::load):
        (JSC::DFG::GetByOffsetMethod::loadFromPrototype):
        (JSC::DFG::GetByOffsetMethod::operator!):
        (JSC::DFG::GetByOffsetMethod::kind):
        (JSC::DFG::GetByOffsetMethod::prototype):
        (JSC::DFG::GetByOffsetMethod::offset):
        (JSC::DFG::MultiGetByOffsetCase::MultiGetByOffsetCase):
        (JSC::DFG::MultiGetByOffsetCase::set):
        (JSC::DFG::MultiGetByOffsetCase::method):
        * dfg/DFGNode.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
        * jit/Repatch.cpp:
        (JSC::repatchByIdSelfAccess):
        (JSC::checkObjectPropertyCondition):
        (JSC::checkObjectPropertyConditions):
        (JSC::replaceWithJump):
        (JSC::generateByIdStub):
        (JSC::actionForCell):
        (JSC::tryBuildGetByIDList):
        (JSC::emitPutReplaceStub):
        (JSC::emitPutTransitionStub):
        (JSC::tryCachePutByID):
        (JSC::tryBuildPutByIdList):
        (JSC::tryRepatchIn):
        (JSC::addStructureTransitionCheck): Deleted.
        (JSC::emitPutTransitionStubAndGetOldStructure): Deleted.
        * runtime/IntendedStructureChain.cpp: Removed.
        * runtime/IntendedStructureChain.h: Removed.
        * runtime/JSCJSValue.h:
        * runtime/JSObject.cpp:
        (JSC::throwTypeError):
        (JSC::JSObject::convertToDictionary):
        (JSC::JSObject::shiftButterflyAfterFlattening):
        * runtime/JSObject.h:
        (JSC::JSObject::flattenDictionaryObject):
        (JSC::JSObject::convertToDictionary): Deleted.
        * runtime/Operations.h:
        (JSC::normalizePrototypeChain):
        (JSC::normalizePrototypeChainForChainAccess): Deleted.
        (JSC::isPrototypeChainNormalized): Deleted.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::slotBase):
        * runtime/Structure.cpp:
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::attributeChangeTransition):
        (JSC::Structure::toDictionaryTransition):
        (JSC::Structure::toCacheableDictionaryTransition):
        (JSC::Structure::toUncacheableDictionaryTransition):
        (JSC::Structure::ensurePropertyReplacementWatchpointSet):
        (JSC::Structure::startWatchingPropertyForReplacements):
        (JSC::Structure::didCachePropertyReplacement):
        (JSC::Structure::dump):
        * runtime/Structure.h:
        * runtime/VM.h:
        * tests/stress/fold-multi-get-by-offset-to-get-by-offset-without-folding-the-structure-check-new.js: Added.
        (foo):
        (bar):
        (baz):
        * tests/stress/multi-get-by-offset-self-or-proto.js: Added.
        (foo):
        * tests/stress/replacement-watchpoint-dictionary.js: Added.
        (foo):
        * tests/stress/replacement-watchpoint.js: Added.
        (foo):
        * tests/stress/undefined-access-dictionary-then-proto-change.js: Added.
        (foo):
        * tests/stress/undefined-access-then-proto-change.js: Added.
        (foo):

2015-07-23  Filip Pizlo  <fpizlo@apple.com>

        DFG::safeToExecute() is wrong for MultiGetByOffset, doesn't consider the structures of the prototypes that get loaded from
        https://bugs.webkit.org/show_bug.cgi?id=147250

        Reviewed by Geoffrey Garen.
        
        This fixes a nasty - but currently benign - bug in DFG::safeToExecute(). That function
        will tell you if hoisting a node to some point is safe in the sense that the node will
        not crash the VM if it executes at that point. A node may be unsafe to execute if we
        cannot prove that at that point, the memory it is loading is not garbage. This is a
        necessarily loose notion - for example it's OK to hoist a load if we haven't proved
        that the load makes semantic sense at that point, since anyway the place where the node
        did get used will still be guarded by any such semantic checks. But because we may also
        hoist uses of the load, we need to make sure that it doesn't produce a garbage value.
        Also, we need to ensure that the load won't trap. Hence safeToExecute() returns true
        anytime we can be sure that a node will not produce a garbage result (i.e. a malformed
        JSValue or object pointer) and will not trap when executed at the point in question.
        
        The bug is that this verification isn't performed for the loads from prototypes inside
        MultiGetByOffset. DFG::ByteCodeParser will guard MultiGetByOffset with CheckStructure's
        on the prototypes. So, hypothetically, you might end up hoisting a MultiGetByOffset
        above those structure checks, which would mean that we might load a value from a memory
        location without knowing that the location is valid. It might then return the value
        loaded.
        
        This never happens in practice. Those structure checks are more hoistable that the
        MultiGetByOffset, since they read a strict subset of the MultiGetByOffset's abstract
        heap reads. Also, we hoist in program order. So, those CheckStructure's will always be
        hoisted before the MultiGetByOffset gets hoisted.
        
        But we should fix this anyway. DFG::safeToExecute() has a clear definition of what a
        "true" return means for IR transformations, and it fails in satisfying that definition
        for MultiGetByOffset.
        
        There are various approaches we can use for making this safe. I considered two:
        
        1) Have MultiGetByOffset refer to the prototypes it is loading from in IR, so that we
           can check if it's safe to load from them.
        
        2) Turn off MultiGetByOffset hoisting when it will emit loads from prototypes, and the
           prototype structure isn't being watched.
        
        I ended up using (2), because it will be the most natural solution once I finish
        https://bugs.webkit.org/show_bug.cgi?id=146929. Already now, it's somewhat more natural
        than (1) since that requires more extensive IR changes. Also, (2) will give us what we
        want in *most* cases: we will usually watch the prototype structure, and we will
        usually constant-fold loads from prototypes. Both of these usually-true things would
        have to become false for MultiGetByOffset hoisting to be disabled by this change.
        
        This change also adds my attempt at a test, though it's not really a test of this bug.
        This bug is currently benign. But, the test does at least trigger the logic to run,
        which is better than nothing.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * tests/stress/multi-get-by-offset-hoist-around-structure-check.js: Added.
        (foo):

2015-07-12  Filip Pizlo  <fpizlo@apple.com>

        If Watchpoint::fire() looks at the state of the world, it should definitely see its set invalidated, and maybe it should see the object of interest in the transitioned-to state
        https://bugs.webkit.org/show_bug.cgi?id=146897

        Reviewed by Mark Lam.
        
        The idea is to eventually support adaptive watchpoints. An adaptive watchpoint will be
        able to watch for a condition that is more fine-grained than any one watchpoint set. For
        example, we might watch a singleton object to see if it ever acquires a property called
        "foo". So long as it doesn't have such a property, we don't want to invalidate any code.
        But if it gets that property, then we should deoptimize. Current watchpoints will
        invalidate code as soon as any property is added (or deleted), because they will use the
        transition watchpoint set of the singleton object's structure, and that fires anytime
        there is any transition.
        
        An adaptive watchpoint would remember the singleton object, and when it got fired, it
        would check if the object's new structure has the property "foo". If not, it would check
        if the object's new structure is watchable (i.e. has a valid transition watchpoint set).
        If the property is missing and the structure is watchable, it would add itself to the
        watchpoint set of the new structure. Otherwise, it would deoptimize.
        
        There are two problems with this idea, and this patch fixes these problems. First, we
        usually fire the transition watchpoint before we do the structure transition. This means
        that if the fire() method looked at the singleton object's structure, it would see the old
        structure, not the new one. It would have no way of knowing what the new structure is.
        Second, inside the fire() method, the watchpoint set being invalidated still appears
        valid, since we change the state after we fire all watchpoints.
        
        This patch addresses both issues. Now, in the most important case (addPropertyTransition),
        we fire the watchpoint set after we have modified the object. This is accomplished using
        a deferral scope called DeferredStructureTransitionWatchpointFire. In cases where there is
        no deferral, the adaptive watchpoint will conservatively resort to deoptimization because
        it would find that the singleton object's structure is no longer watchable. This is
        because in the absence of deferral, the singleton object would still have the original
        structure, but that structure's watchpoint set would now report itself as having been
        invalidated.

        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::fireAllSlow): Change the state of the set before firing all watchpoints.
        (JSC::WatchpointSet::fireAllWatchpoints):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal): Use the deferral scope.
        * runtime/Structure.cpp:
        (JSC::Structure::Structure): Pass the deferral scope to didTransitionFromThisStructure.
        (JSC::Structure::addPropertyTransition): Pass the deferral scope to create().
        (JSC::StructureFireDetail::dump): This is no longer anonymous.
        (JSC::DeferredStructureTransitionWatchpointFire::DeferredStructureTransitionWatchpointFire): Start with a null structure.
        (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire): Fire the watchpoint if there is a structure.
        (JSC::DeferredStructureTransitionWatchpointFire::add): Add a structure. Logically this is a list of deferred things, but we assert that there only will be one (happens to be true now).
        (JSC::Structure::didTransitionFromThisStructure): Defer the watchpoint firing if there is a deferral scope.
        * runtime/Structure.h:
        (JSC::StructureFireDetail::StructureFireDetail): Move this to the header.
        * runtime/StructureInlines.h:
        (JSC::Structure::create): Pass the deferral scope to the constructor.

2016-01-05  Keith Miller  <keith_miller@apple.com>

        [ES6] Arrays should be subclassable.
        https://bugs.webkit.org/show_bug.cgi?id=152706

        Reviewed by Benjamin Poulain.

        This patch enables full subclassing of Arrays. We do this by fetching the new.target's prototype property
        in the Array constructor and transitioning the old structure to have the new prototype. This method has
        two downsides. The first is that we clobber the transition watchpoint on the base structure. The second,
        which is currently very significant but should be fixed in a future patch, is that we allocate a new
        structure for each new derived class we allocate.

        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        (JSC::constructWithArrayConstructor):
        (JSC::callArrayConstructor):
        * runtime/ArrayConstructor.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
        (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/PrototypeMap.h:
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::createSubclassStructure):
        * tests/es6.yaml:
        * tests/stress/class-subclassing-array.js: Added.
        (A):
        (B.prototype.get 1):
        (B):
        (C):
        (test):

2015-07-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        Add newTarget accessor to JS constructor written in C++
        https://bugs.webkit.org/show_bug.cgi?id=147160

        Reviewed by Geoffrey Garen.

        This patch adds `ExecState#newTarget()` which returns `new.target` defined in ECMA262 6th.
        It enables some C++ constructors (like Intl.XXX constructors) to leverage this to complete
        its implementation.

        When the constructor is called, |this| in the arguments is used for storing new.target instead.
        So by adding the accessor for |this|, JS constructor written in C++ can access new.target.

        And at the same time, this patch extends the existing `construct` to accept new.target value.
        It is corresponding to the spec's Construct abstract operation.

        * interpreter/CallFrame.h:
        (JSC::ExecState::newTarget):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeConstruct):
        * interpreter/Interpreter.h:
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        (JSC::construct):

2016-01-22  Keith Miller  <keith_miller@apple.com>

        [ES6] Add Symbol.species properties to the relevant constructors
        https://bugs.webkit.org/show_bug.cgi?id=153339

        Reviewed by Michael Saboff.

        This patch adds Symbol.species to the RegExp, Array, TypedArray, Map, Set, ArrayBuffer, and
        Promise constructors.  The functions that use these properties will be added in a later
        patch.

        * builtins/GlobalObject.js:
        (speciesGetter):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/BooleanConstructor.h:
        (JSC::BooleanConstructor::create):
        * runtime/CommonIdentifiers.h:
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::create):
        * runtime/ErrorConstructor.h:
        (JSC::ErrorConstructor::create):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        (JSC::JSArrayBufferConstructor::create):
        * runtime/JSArrayBufferConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::create):
        * runtime/JSInternalPromiseConstructor.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::create):
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/JSPromiseConstructor.h:
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        (JSC::JSTypedArrayViewConstructor::create): Deleted.
        * runtime/JSTypedArrayViewConstructor.h:
        (JSC::JSTypedArrayViewConstructor::create):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/MapConstructor.h:
        (JSC::MapConstructor::create):
        * runtime/NumberConstructor.h:
        (JSC::NumberConstructor::create):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::create):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/SetConstructor.h:
        (JSC::SetConstructor::create):
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::create):
        * runtime/SymbolConstructor.h:
        (JSC::SymbolConstructor::create):
        * runtime/WeakMapConstructor.h:
        (JSC::WeakMapConstructor::create):
        * runtime/WeakSetConstructor.h:
        (JSC::WeakSetConstructor::create):
        * tests/stress/symbol-species.js: Added.
        (testSymbolSpeciesOnConstructor):

2016-03-25  Keith Miller  <keith_miller@apple.com>

        putByIndexBeyondVectorLengthWithoutAttributes should not crash if it can't ensureLength
        https://bugs.webkit.org/show_bug.cgi?id=155730

        Reviewed by Saam Barati.

        This patch makes ensureLength return a boolean indicating if it was able to set the length.
        ensureLength also no longer sets the butterfly to null if the allocation of the butterfly
        fails. All of ensureLengths callers including putByIndexBeyondVectorLengthWithoutAttributes
        have been adapted to throw an out of memory error if ensureLength fails.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::ensureLengthSlow):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength):

2016-02-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Introduce BytecodeIntrinsic constant rep like @undefined
        https://bugs.webkit.org/show_bug.cgi?id=153737

        Reviewed by Darin Adler.

        This patch enhances existing BytecodeIntrinsic mechanism to accept `@xxx` form,
        that will be used to represent bytecode intrinsic constants.
        After this change, we can use 2 forms for bytecode intrinsics. (1) Function form (like, @toString(value))
        and (2) Constant form (like @undefined).

        Bytecode intrinsic constants allow us to easily expose constant values from C++ world.
        For example, we can expose ArrayIterationKind flags to JS world without using private global variables.
        Exposed constant values are loaded from bytecodes directly through constant registers.
        While previously we expose them through private global variables, bytecode intrinsic constants
        can be loaded directly from CodeBlock. And later, it will become JSConstant in DFG.

        And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc.

        * builtins/ArrayConstructor.js:
        (from):
        * builtins/ArrayIteratorPrototype.js:
        (next):
        * builtins/ArrayPrototype.js:
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort.compactSparse):
        (sort.compactSlow):
        (sort.compact):
        (sort):
        (copyWithin):
        * builtins/DatePrototype.js:
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleString):
        (toLocaleDateString.toDateTimeOptionsDateDate):
        (toLocaleDateString):
        (toLocaleTimeString.toDateTimeOptionsTimeTime):
        (toLocaleTimeString):
        * builtins/GeneratorPrototype.js:
        (generatorResume):
        * builtins/GlobalObject.js:
        (isDictionary):
        * builtins/InternalPromiseConstructor.js:
        (internalAll.newResolveElement):
        (internalAll):
        * builtins/IteratorPrototype.js:
        (symbolIteratorGetter):
        (symbolIterator): Deleted.
        * builtins/MapPrototype.js:
        (forEach):
        * builtins/ModuleLoaderObject.js:
        (newRegistryEntry):
        (forceFulfillPromise):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestLink):
        (provide):
        * builtins/PromiseConstructor.js:
        (all.newResolveElement):
        (all):
        (race):
        (reject):
        (resolve):
        * builtins/PromiseOperations.js:
        (newPromiseCapability.executor):
        (newPromiseCapability):
        (rejectPromise):
        (fulfillPromise):
        (createResolvingFunctions.resolve):
        (createResolvingFunctions.reject):
        (createResolvingFunctions):
        (promiseReactionJob):
        (promiseResolveThenableJob):
        (initializePromise):
        * builtins/PromisePrototype.js:
        (catch):
        (then):
        * builtins/SetPrototype.js:
        (forEach):
        * builtins/StringConstructor.js:
        (raw):
        * builtins/StringIteratorPrototype.js:
        (next):
        * builtins/StringPrototype.js:
        (localeCompare):
        * builtins/TypedArrayConstructor.js:
        (of):
        (from):
        * builtins/TypedArrayPrototype.js:
        (every):
        (find):
        (findIndex):
        (forEach):
        (some):
        (reduce):
        (reduceRight):
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/NodesCodegen.cpp:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/NodeConstructors.h:
        (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBytecodeIntrinsicNode):
        (JSC::BytecodeIntrinsicNode::type):
        (JSC::BytecodeIntrinsicNode::emitter):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createResolve):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry): Deleted.
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::bytecodeIntrinsicRegistry):

2017-06-26  Saam Barati  <sbarati@apple.com>

        Crash in JSC::Lexer<unsigned char>::setCode
        https://bugs.webkit.org/show_bug.cgi?id=172754

        Reviewed by Mark Lam.

        The lexer was asking one of its buffers to reserve initial space that
        was O(text size in bytes). For large sources, this would end up causing
        the vector to overflow and crash. This patch changes this code be like
        the Lexer's other buffers and to only reserve a small starting buffer.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):

2017-05-25  Saam Barati  <sbarati@apple.com>

        Cherry-pick r217438. rdar://problem/32385704

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::popIndexedForInScope):
        (JSC::BytecodeGenerator::popStructureForInScope):
        (JSC::BytecodeGenerator::invalidateForInContextForLocal):
        (JSC::StructureForInContext::finalize):
        (JSC::IndexedForInContext::finalize):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::StructureForInContext::addGetInst):
        (JSC::IndexedForInContext::addGetInst):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_nop):
        * llint/LowLevelInterpreter.asm:

2015-08-17 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] Implement ES6 arrow function syntax. Arrow function specific features. Lexical bind of this
        https://bugs.webkit.org/show_bug.cgi?id=144956

        Reviewed by Saam Barati.

        Added support of ES6 arrow function specific feature, lexical bind of this and no constructor. http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
        In patch were implemented the following cases:
           this - variable |this| is point to the |this| of the function where arrow function is declared. Lexical bind of |this|
           constructor - the using of the command |new| for arrow function leads to runtime error
           call(), apply(), bind()  - methods can only pass in arguments, but has no effect on |this| 


        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::isArrowFunction):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionThis):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrowFuncExprNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::isFunctionAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileLoadArrowFunctionThis):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileLoadArrowFunctionThis):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/Interpreter.cpp:
        * interpreter/Interpreter.h:
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState): Added 3 arguments version for windows build.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_load_arrowfunction_this):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_arrow_func_exp):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_load_arrowfunction_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::createArrowFunctionExpr):
        * parser/NodeConstructors.h:
        (JSC::BaseFuncExprNode::BaseFuncExprNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isArrowFuncExprNode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionMetadata):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/Executable.h:
        * runtime/JSArrowFunction.cpp: Added.
        (JSC::JSArrowFunction::destroy):
        (JSC::JSArrowFunction::create):
        (JSC::JSArrowFunction::JSArrowFunction):
        (JSC::JSArrowFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSArrowFunction::visitChildren):
        (JSC::JSArrowFunction::getConstructData):
        * runtime/JSArrowFunction.h: Added.
        (JSC::JSArrowFunction::allocationSize):
        (JSC::JSArrowFunction::createImpl):
        (JSC::JSArrowFunction::boundThis):
        (JSC::JSArrowFunction::createStructure):
        (JSC::JSArrowFunction::offsetOfThisValue):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::JSFunction):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrowFunctionStructure):
        * tests/stress/arrowfunction-activation-sink-osrexit-default-value-tdz-error.js: Added.
        * tests/stress/arrowfunction-activation-sink-osrexit-default-value.js: Added.
        * tests/stress/arrowfunction-activation-sink-osrexit.js: Added.
        * tests/stress/arrowfunction-activation-sink.js: Added.
        * tests/stress/arrowfunction-bound.js: Added.
        * tests/stress/arrowfunction-call.js: Added.
        * tests/stress/arrowfunction-constructor.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-3.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-4.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-5.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-6.js: Added.
        * tests/stress/arrowfunction-lexical-this-activation-sink-osrexit.js: Added.
        * tests/stress/arrowfunction-lexical-this-activation-sink.js: Added.
        * tests/stress/arrowfunction-lexical-this-sinking-no-double-allocate.js: Added.
        * tests/stress/arrowfunction-lexical-this-sinking-osrexit.js: Added.
        * tests/stress/arrowfunction-lexical-this-sinking-put.js: Added.
        * tests/stress/arrowfunction-others.js: Added.
        * tests/stress/arrowfunction-run-10-1.js: Added.
        * tests/stress/arrowfunction-run-10-2.js: Added.
        * tests/stress/arrowfunction-run-10000-1.js: Added.
        * tests/stress/arrowfunction-run-10000-2.js: Added.
        * tests/stress/arrowfunction-sinking-no-double-allocate.js: Added.
        * tests/stress/arrowfunction-sinking-osrexit.js: Added.
        * tests/stress/arrowfunction-sinking-put.js: Added.
        * tests/stress/arrowfunction-tdz.js: Added.
        * tests/stress/arrowfunction-typeof.js: Added.

2015-07-17  Saam barati  <saambarati1@gmail.com>

        Function parameters should be parsed in the same parser arena as the function body
        https://bugs.webkit.org/show_bug.cgi?id=145995

        Reviewed by Yusuke Suzuki.

        This patch changes how functions are parsed in JSC. A function's
        parameters are now parsed in the same arena as the function itself.
        This allows us to arena allocate all destructuring AST nodes and
        the FunctionParameters node. This will help make implementing ES6
        default parameter values sane.

        A source code that represents a function now includes the text of the function's 
        parameters. The starting offset is at the opening parenthesis of the parameter
        list or at the starting character of the identifier for arrow functions that
        have single arguments and don't start with parenthesis.

        For example:

        "function (param1, param2) { ... }"
                                   ^
                                   | This offset used to be the starting offset of a function's SourceCode
                  ^
                  | This is the new starting offset for a function's SourceCode.

        This requires us to change how some offsets are calculated
        and also requires us to report some different line numbers for internal
        metrics that use a SourceCode's starting line and column numbers.

        This patch also does a bit of cleanup with regards to how
        functions are parsed in general (especially arrow functions).
        It removes some unnecessary #ifdefs and the likes for arrow
        to make things clearer and more deliberate.

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedFunctionExecutable::parameterCount): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::DestructuringAssignmentNode::emitBytecode):
        (JSC::assignDefaultValueIfUndefined):
        (JSC::ArrayPatternNode::collectBoundIdentifiers):
        (JSC::DestructuringPatternNode::~DestructuringPatternNode): Deleted.
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createClassExpr):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createElementList):
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::appendParameter):
        (JSC::ASTBuilder::createClause):
        (JSC::ASTBuilder::createClauseList):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createForOfLoop):
        (JSC::ASTBuilder::isResolve):
        (JSC::ASTBuilder::createDestructuringAssignment):
        (JSC::ASTBuilder::createArrayPattern):
        (JSC::ASTBuilder::appendArrayPatternSkipEntry):
        (JSC::ASTBuilder::appendArrayPatternEntry):
        (JSC::ASTBuilder::appendArrayPatternRestEntry):
        (JSC::ASTBuilder::finishArrayPattern):
        (JSC::ASTBuilder::createObjectPattern):
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::createBindingLocation):
        (JSC::ASTBuilder::setEndOffset):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::nextTokenIsColon):
        (JSC::Lexer<T>::setTokenPosition):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::clear):
        * parser/Lexer.h:
        (JSC::Lexer::setIsReparsingFunction):
        (JSC::Lexer::isReparsingFunction):
        (JSC::Lexer::lineNumber):
        (JSC::Lexer::setIsReparsing): Deleted.
        (JSC::Lexer::isReparsing): Deleted.
        * parser/NodeConstructors.h:
        (JSC::TryNode::TryNode):
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::ArrayPatternNode::ArrayPatternNode):
        (JSC::ObjectPatternNode::ObjectPatternNode):
        (JSC::BindingNode::BindingNode):
        (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
        (JSC::ParameterNode::ParameterNode): Deleted.
        (JSC::ArrayPatternNode::create): Deleted.
        (JSC::ObjectPatternNode::create): Deleted.
        (JSC::BindingNode::create): Deleted.
        * parser/Nodes.cpp:
        (JSC::ProgramNode::ProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::finishParsing):
        (JSC::FunctionNode::FunctionNode):
        (JSC::FunctionNode::finishParsing):
        (JSC::FunctionParameters::create): Deleted.
        (JSC::FunctionParameters::FunctionParameters): Deleted.
        (JSC::FunctionParameters::~FunctionParameters): Deleted.
        * parser/Nodes.h:
        (JSC::ProgramNode::startColumn):
        (JSC::ProgramNode::endColumn):
        (JSC::EvalNode::startColumn):
        (JSC::EvalNode::endColumn):
        (JSC::FunctionParameters::size):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::append):
        (JSC::FuncExprNode::body):
        (JSC::DestructuringPatternNode::~DestructuringPatternNode):
        (JSC::DestructuringPatternNode::isBindingNode):
        (JSC::DestructuringPatternNode::emitDirectBinding):
        (JSC::ArrayPatternNode::appendIndex):
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::BindingNode::boundProperty):
        (JSC::BindingNode::divotStart):
        (JSC::BindingNode::divotEnd):
        (JSC::DestructuringAssignmentNode::bindings):
        (JSC::FuncDeclNode::body):
        (JSC::ParameterNode::pattern): Deleted.
        (JSC::ParameterNode::nextParam): Deleted.
        (JSC::FunctionParameters::patterns): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::~Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::allowAutomaticSemicolon):
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
        (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
        (JSC::Parser<LexerType>::parseSwitchClauses):
        (JSC::Parser<LexerType>::parseSwitchDefaultClause):
        (JSC::Parser<LexerType>::parseBlockStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        (JSC::operatorString):
        (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody): Deleted.
        * parser/Parser.h:
        (JSC::Parser::positionBeforeLastNewline):
        (JSC::Parser::locationBeforeLastToken):
        (JSC::Parser::findCachedFunctionInfo):
        (JSC::Parser::isofToken):
        (JSC::Parser::isEndOfArrowFunction):
        (JSC::Parser::isArrowFunctionParamters):
        (JSC::Parser::tokenStart):
        (JSC::Parser::isLETMaskedAsIDENT):
        (JSC::Parser::autoSemiColon):
        (JSC::Parser::setEndOfStatement):
        (JSC::Parser::canRecurse):
        (JSC::Parser<LexerType>::parse):
        (JSC::parse):
        * parser/ParserFunctionInfo.h:
        * parser/ParserModes.h:
        (JSC::functionNameIsInScope):
        * parser/SourceCode.h:
        (JSC::makeSource):
        (JSC::SourceCode::subExpression):
        (JSC::SourceCode::subArrowExpression): Deleted.
        * parser/SourceProviderCache.h:
        (JSC::SourceProviderCache::get):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::endFunctionToken):
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::writtenVariables):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::SyntaxChecker):
        (JSC::SyntaxChecker::createClassExpr):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createArrowFunctionExpr):
        (JSC::SyntaxChecker::setFunctionNameStart):
        (JSC::SyntaxChecker::createArguments):
        (JSC::SyntaxChecker::createPropertyList):
        (JSC::SyntaxChecker::createElementList):
        (JSC::SyntaxChecker::createFormalParameterList):
        (JSC::SyntaxChecker::appendParameter):
        (JSC::SyntaxChecker::createClause):
        (JSC::SyntaxChecker::createClauseList):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * tests/controlFlowProfiler/conditional-expression.js:
        (testConditionalFunctionCall):

2016-11-03  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r208299. rdar://problem/28857505

    2016-11-02  Michael Saboff  <msaboff@apple.com>

            Crash beneath SlotVisitor::drain @ cooksillustrated.com
            https://bugs.webkit.org/show_bug.cgi?id=164304

            Reviewed by Mark Lam.

            Added back write barrier for the base cell of put-by_id in the LLInt when the structure is
            changed.  Also removed the unused macro "storeStructureWithTypeInfo".

            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:

2017-04-05  Guilherme Iscaro  <iscaro@profusion.mobi>

        Do not use BLX for immediates (ARM-32)

        https://bugs.webkit.org/show_bug.cgi?id=170351

        Reviewed by Mark Lam.

        Currently the offline asm generator for 32-bit ARM code translates the
        'call' meta-instruction (which may be found in LowLevelInterpreter.asm
        and friends) to the ARM's BLX instrunction. The BLX instruction may be
        used for labels (immediates) and registers and one side effect of BLX
        is that it may switch the processor's instruction set.
        A 'BLX register' instruction will change/remain the processor state to
        ARM if the  register_bit[0] is set to 0 or change/remain to Thumb if
        register_bit[0] is set to 1. However, a 'BLX label' instruction will
        always switch the processor state. It switches ARM to thumb and vice-versa.
        This behaviour is unwanted, since the C++ code and the offlineasm generated code
        are both compiled using the same instruction set, thus a instruction
        set change will likely produce a crash. In order to fix the problem the
        BL instruction can be used for labels. It will branch just like BLX,
        but it won't change the instruction set. It's important to note that
        Darwin is not affected by this problem, thus to minimize the impact of
        this change the BL instruction will only be used on non-darwin targets.

        BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20

        * offlineasm/arm.rb:

2016-12-23  Mark Lam  <mark.lam@apple.com>

        Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
        https://bugs.webkit.org/show_bug.cgi?id=166466

        Reviewed by Keith Miller.

        * runtime/VM.cpp:
        (JSC::VM::throwException):

2017-05-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r215748. rdar://problem/31971413

    2017-04-25  Mark Lam  <mark.lam@apple.com>

            Local CSE wrongly CSEs array accesses with different result types.
            https://bugs.webkit.org/show_bug.cgi?id=170990
            <rdar://problem/31705945>

            Reviewed by Saam Barati.

            The fix is to use different LocationKind enums for the different type of array
            result types.  This makes the HeapLocation values different based on the result
            types, and allows CSE to discern between them.

            * dfg/DFGCSEPhase.cpp:
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGHeapLocation.cpp:
            (WTF::printInternal):
            * dfg/DFGHeapLocation.h:
            (JSC::DFG::indexedPropertyLocForResultType):

2017-05-09  Matthew Hanson  <matthew_hanson@apple.com>

        Cherry-pick r215351. rdar://problem/31631922

    2017-04-13  Mark Lam  <mark.lam@apple.com>

            Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
            https://bugs.webkit.org/show_bug.cgi?id=170661
            <rdar://problem/31579046>

            Reviewed by Filip Pizlo.

            Previously, we were using flush() to flush the outermost frame's scopeRegister.
            This is incorrect because flush() expects the VirtualRegister value passed to
            it to be that of the top most inlined frame.  In the event that we reach a
            terminal condition while inside an inlined frame, flush() will end up flushing
            the wrong register.  The fix is simply to use flushDirect() instead.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::flush):

2016-10-11  Mark Lam  <mark.lam@apple.com>

        Array.prototype.concat should not modify frozen objects.
        https://bugs.webkit.org/show_bug.cgi?id=163302

        Reviewed by Filip Pizlo.

        The ES6 spec for Array.prototype.concat states that it uses the
        CreateDataPropertyOrThrow() to add items to the result array.  The spec for
        CreateDataPropertyOrThrow states:

        "This abstract operation creates a property whose attributes are set to the same
        defaults used for properties created by the ECMAScript language assignment
        operator. Normally, the property will not already exist. If it does exist and is
        not configurable or if O is not extensible, [[DefineOwnProperty]] will return
        false causing this operation to throw a TypeError exception."

        Since the properties of frozen objects are not extensible, not configurable, and
        not writable, Array.prototype.concat should fail to write to the result array if
        it is frozen.

        Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
        https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
        https://tc39.github.io/ecma262/#sec-createdataproperty.

        The fix consists of 2 parts:
        1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
           putDirectIndex(), and
        2. SparseArrayValueMap::putDirect() should check for the case where the property
           is read only.

        (2) ensures that we don't write into a non-writable property.
        (1) ensures that we throw a TypeError for attempts to write to a non-writeable
        property.

        * runtime/ArrayPrototype.cpp:
        (JSC::moveElements):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putDirect):

2017-03-28  Jason Marcell  <jmarcell@apple.com>

        Merge r214240. rdar://problem/31178794

    2017-03-21  Mark Lam  <mark.lam@apple.com>

            The DFG Integer Check Combining phase should force an OSR exit for CheckInBounds on a negative constant min bound.
            https://bugs.webkit.org/show_bug.cgi?id=169933
            <rdar://problem/31105125>

            Reviewed by Filip Pizlo and Geoffrey Garen.

            Also fixed the bit-rotted RangeKey::dump() function.

            * dfg/DFGIntegerCheckCombiningPhase.cpp:
            (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):

2017-02-23  Filip Pizlo  <fpizlo@apple.com>

        verifyEdges should not run in release
        <rdar://problem/30537798>

        Reviewed by Keith Miller and Mark Lam.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2017-02-23  Filip Pizlo  <fpizlo@apple.com>

        Disable concurrent GC A:B testing.

        * runtime/Options.h:

2017-02-16  Keith Miller  <keith_miller@apple.com>

        Fix merge issue with r212085 (rdar://problem/29939864).

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::callerGetter):

2017-02-09  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r212023. rdar://problem/30041640

    2017-02-09  Brent Fulgham  <bfulgham@apple.com>

            Handle synchronous layout when setting a selection range
            https://bugs.webkit.org/show_bug.cgi?id=167092
            <rdar://problem/30041640>

            Reviewed by Antti Koivisto.

            The 'innerTextElement' of a form control can change during layout due
            to arbitrary JavaScript executing. Handle the case where the inner text
            element has changed so that current render box height is while setting
            a selection range.

            Test: fast/forms/input-type-change-during-selection.html

            * html/HTMLTextFormControlElement.cpp:
            (WebCore::HTMLTextFormControlElement::setSelectionRange):

2017-02-09  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r212009. rdar://problem/29939864

    2017-02-09  Keith Miller  <keith_miller@apple.com>

            We should not allow Function.caller to be used on native functions
            https://bugs.webkit.org/show_bug.cgi?id=165628

            Reviewed by Mark Lam.

            Also remove unneeded dynamic cast.

            * runtime/JSFunction.cpp:
            (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
            (JSC::JSFunction::callerGetter):

2017-02-02  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r211463. rdar://problem/30296879

    2017-01-31  Filip Pizlo  <fpizlo@apple.com>

            Make verifyEdge a RELEASE_ASSERT
            <rdar://problem/30296879>

            Rubber stamped by Saam Barati.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2017-01-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r210971. rdar://problem/30115838

    2017-01-20  Saam Barati  <sbarati@apple.com>

            We should flash a safepoint before each DFG/FTL phase
            https://bugs.webkit.org/show_bug.cgi?id=167234

            Reviewed by Filip Pizlo.

            The recent GC changes caused us to regress Kraken because of a
            longstanding issue that happened to be hit with higher frequency because
            of a change in timing between when a particular GC was happening and
            when a particular FTL compilation was happening. The regression is caused
            by the GC was waiting for a large function to make it through the DFG portion
            of an FTL compilation. This was taking 20ms-30ms and started happened during a
            particular test with much higher frequency.

            This means that anytime the GC waits for this compilation, the test ran at least
            ~20ms slower because the GC waits for the compiler threads the mutator is stopped.

            It's good that we have such an easily reproducible case of this performance
            issue because it will effect many real JS programs, especially ones with
            large functions that get hot.

            The most straight forward solution to fix this is to flash a safepoint before
            each phase, allowing the GC to suspend the compiler if needed. In my testing,
            this progresses Kraken in the browser, and doesn't regress anything else. This
            solution also makes the most sense. I did some analysis on the compilation time
            of this function that took ~20-30ms to pass through the DFG phases, and
            the phase times were mostly evenly distributed. Some took longer than others,
            but no phase was longer than 3ms. Most were in the 0.25ms to 1.5ms range.

            * dfg/DFGPlan.cpp:
            (JSC::DFG::Plan::compileInThreadImpl):
            * dfg/DFGSafepoint.cpp:
            (JSC::DFG::Safepoint::begin):
            * runtime/Options.h:

2017-01-18  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r210858. rdar://problem/30069096

    2017-01-18  Filip Pizlo  <fpizlo@apple.com>

            JSObjectSetPrivate should not use jsCast<>
            rdar://problem/30069096

            Reviewed by Keith Miller.

            * API/JSObjectRef.cpp:
            (JSObjectSetPrivate):

2017-01-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r210458. rdar://problem/29911919

    2017-01-06  Mark Lam  <mark.lam@apple.com>

            The ObjC API's JSVirtualMachine's map tables need to be guarded by a lock.
            https://bugs.webkit.org/show_bug.cgi?id=166778
            <rdar://problem/29761198>

            Reviewed by Filip Pizlo.

            Now that we have a concurrent GC, access to JSVirtualMachine's
            m_externalObjectGraph and m_externalRememberedSet need to be guarded by a lock
            since both the GC marker thread and the mutator thread may access them at the
            same time.

            * API/JSVirtualMachine.mm:
            (-[JSVirtualMachine addExternalRememberedObject:]):
            (-[JSVirtualMachine addManagedReference:withOwner:]):
            (-[JSVirtualMachine removeManagedReference:withOwner:]):
            (-[JSVirtualMachine externalDataMutex]):
            (scanExternalObjectGraph):
            (scanExternalRememberedSet):

            * API/JSVirtualMachineInternal.h:
            - Deleted externalObjectGraph method.  There's no need to expose this.

2017-01-06  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r210276. rdar://problem/28867002

    2017-01-04  Saam Barati  <sbarati@apple.com>

            We don't properly handle exceptions inside the nativeCallTrampoline macro in the LLInt
            https://bugs.webkit.org/show_bug.cgi?id=163720

            Reviewed by Mark Lam.

            In the LLInt, we were incorrectly doing the exception check after the call.
            Before the exception check, we were unwinding to our caller's
            frame under the assumption that our caller was always a JS frame.
            This is incorrect, however, because our caller might be a C frame.
            One way that it can be a C frame is when C calls to JS, and JS tail
            calls to native. This patch fixes this bug by doing unwinding from
            the native callee's frame instead of its callers.

            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:

2017-01-06  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r210221. rdar://problem/29449474

    2017-01-01  Jeff Miller  <jeffm@apple.com>

            Update user-visible copyright strings to include 2017
            https://bugs.webkit.org/show_bug.cgi?id=166278

            Reviewed by Dan Bernstein.

            * Info.plist:

2016-10-27  Mark Lam  <mark.lam@apple.com>

        Merge r207518. rdar://problem/28216050, rdar://problem/28216232

    2016-10-18  Mark Lam  <mark.lam@apple.com>

            Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
            https://bugs.webkit.org/show_bug.cgi?id=154377
            <rdar://problem/27330808>

            Reviewed by Filip Pizlo and Saam Barati.

            In a scenario where we cache the __proto__ accessors in global variables, and
            later explicitly invoke those accessors as functions, the spec for Function Calls
            (see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
            ref value is of type Reference, and base of ref is an Environment Record.  Then,
            it follows that the thisValue should be set to refEnv.WithBaseObject()
            (see section 4.b.ii of 12.3.4.1 at
            https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).

            refEnv in this case is the environment record that the cached accessors were
            found in i.e. the global object.  The WithBaseObject() of the global object is
            undefined (see details about WithBaseObject at
            https://tc39.github.io/ecma262/#sec-environment-records).

            Hence, the __proto__ accessors should see a thisValue of undefined, and throw
            TypeErrors.  See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
            https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
            https://tc39.github.io/ecma262/#sec-toobject, and
            https://tc39.github.io/ecma262/#sec-requireobjectcoercible.

            In JSC's implementation, the callee needs to do a ToThis operation on the
            incoming "this" argument in order to get the specified thisValue.  The
            implementations of the __proto__ accessors were not doing this correctly.  This
            has now been fixed.

            * runtime/JSGlobalObjectFunctions.cpp:
            (JSC::globalFuncProtoGetter):
            (JSC::globalFuncProtoSetter):

2016-10-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r207623. rdar://problem/28857477

    2016-10-20  Keith Miller  <keith_miller@apple.com>

            Invalid assertion in arguments elimination
            https://bugs.webkit.org/show_bug.cgi?id=163740
            <rdar://problem/27911462>

            Reviewed by Michael Saboff.

            The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
            child would always be a CreateDirectArguments.  While we only create the
            op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
            number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
            example, if we are OSR entering in some function with direct arguments the
            CreateDirectArguments node might become ExtractOSREntryLocals.

            * dfg/DFGArgumentsEliminationPhase.cpp:

2016-10-12  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r206955. rdar://problem/28216236

    2016-10-08  Saam Barati  <sbarati@apple.com>

            HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
            https://bugs.webkit.org/show_bug.cgi?id=159942
            <rdar://problem/27328836>

            Reviewed by Filip Pizlo.

            When HasIndexedProperty has a ForceOSRExit array mode, it should
            report to write to side state, like the ForceOSRExit node, and the
            other nodes with ForceOSRExit array mode.

            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):

2016-10-12  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r204612. rdar://problem/28216278

    2016-08-18  Mark Lam  <mark.lam@apple.com>

            ScopedArguments is using the wrong owner object for a write barrier.
            https://bugs.webkit.org/show_bug.cgi?id=160976
            <rdar://problem/27328506>

            Reviewed by Keith Miller.

            * runtime/ScopedArguments.h:
            (JSC::ScopedArguments::setIndexQuickly):

2016-09-14  Babak Shafiei  <bshafiei@apple.com>

        Merge r205882. rdar://problem/28233331

    2016-09-13  Mark Lam  <mark.lam@apple.com>

            DFG NewArrayBuffer node should watch for "have a bad time" state change.
            https://bugs.webkit.org/show_bug.cgi?id=161927
            <rdar://problem/27995222>

            Reviewed by Geoffrey Garen.

            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):

2016-09-13  Babak Shafiei  <bshafiei@apple.com>

        Merge r205895. rdar://problem/28287070

    2016-09-13  Michael Saboff  <msaboff@apple.com>

            Promises aren't resolved properly when making a ObjC API callback
            https://bugs.webkit.org/show_bug.cgi?id=161929

            Reviewed by Geoffrey Garen.

            When we go to call out to an Objective C function registered via the API,
            we first drop all JSC locks to make the call.  As part of dropping the locks,
            we drain the microtask queue that is used among other things for handling deferred
            promise resolution.  The DropAllLocks scope class that drops the locks while in
            scope, resets the current thread's AtomicStringTable to the default table.  This
            is wrong for two reasons, first it happens before we drain the microtask queue and
            second it isn't needed as JSLock::willReleaseLock() restores the current thread's
            AtomicStringTable to the table before the lock was acquired.

            In fact, the manipulation of the current thread's AtomicStringTable is already
            properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
            Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
            and destructor should be removed.

            * API/tests/testapi.mm:
            (testObjectiveCAPIMain): Added a new test.
            * runtime/JSLock.cpp:
            (JSC::JSLock::DropAllLocks::DropAllLocks):
            (JSC::JSLock::DropAllLocks::~DropAllLocks):

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r204485. rdar://problem/27991572

    2016-08-15  Mark Lam  <mark.lam@apple.com>

            Make JSValue::strictEqual() handle failures to resolve JSRopeStrings.
            https://bugs.webkit.org/show_bug.cgi?id=160832
            <rdar://problem/27577556>

            Reviewed by Geoffrey Garen.

            Currently, JSValue::strictEqualSlowCaseInline() (and peers) will blindly try to
            access the StringImpl of a JSRopeString that fails to resolve its rope.  As a
            result, we'll crash with null pointer dereferences.

            We can fix this by introducing a JSString::equal() method that will do the
            equality comparison, but is aware of the potential failures to resolve ropes.
            JSValue::strictEqualSlowCaseInline() (and peers) will now call JSString::equal()
            instead of accessing the underlying StringImpl directly.

            Also added some exception checks.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * jit/JITOperations.cpp:
            * runtime/ArrayPrototype.cpp:
            (JSC::arrayProtoFuncIndexOf):
            (JSC::arrayProtoFuncLastIndexOf):
            * runtime/JSCJSValueInlines.h:
            (JSC::JSValue::equalSlowCaseInline):
            (JSC::JSValue::strictEqualSlowCaseInline):
            * runtime/JSString.cpp:
            (JSC::JSString::equalSlowCase):
            * runtime/JSString.h:
            * runtime/JSStringInlines.h: Added.
            (JSC::JSString::equal):

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r203381. rdar://problem/27860536

    2016-07-18  Anders Carlsson  <andersca@apple.com>

            WebKit nightly fails to build on macOS Sierra
            https://bugs.webkit.org/show_bug.cgi?id=159902
            rdar://problem/27365672

            Reviewed by Tim Horton.

            * icu/unicode/ucurr.h: Added.
            Add ucurr.h from ICU.

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r205192. rdar://problem/28097740

    2016-08-30  Alex Christensen  <achristensen@webkit.org>

            Fix WebInspectorUI in internal Windows build
            https://bugs.webkit.org/show_bug.cgi?id=161221
            rdar://problem/28019023

            Reviewed by Brent Fulgham and Joseph Pecoraro.

            * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204570. rdar://problem/27991567

    2016-08-17  Mark Lam  <mark.lam@apple.com>

            Remove an invalid assertion in the DFG backend's GetById emitter.
            https://bugs.webkit.org/show_bug.cgi?id=160925
            <rdar://problem/27248961>

            Reviewed by Filip Pizlo.

            The DFG backend's GetById assertion that the node's prediction not be SpecNone
            is just plain wrong.  It assumes that we can never have a GetById node without a
            type prediction, but this is not true.  The following test case proves otherwise:

                function foo() {
                    "use strict";
                    return --arguments["callee"];
                }

            Will remove the assertion.  Nothing else needs to change as the DFG is working
            correctly without the assertion.

            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204362. rdar://problem/27991421

    2016-08-10  Michael Saboff  <msaboff@apple.com>

            Baseline GetByVal and PutByVal for cache ID stubs need to handle exceptions
            https://bugs.webkit.org/show_bug.cgi?id=160749

            Reviewed by Filip Pizlo.

            We were emitting "callOperation()" calls in emitGetByValWithCachedId() and
            emitPutByValWithCachedId() without linking the exception checks created by the
            code emitted.  This manifested itself in various ways depending on the processor.
            This is due to what the destination is for an unlinked branch.  On X86, an unlinked
            branch goes tot he next instructions.  On ARM64, we end up with an infinite loop
            as we branch to the same instruction.  On ARM we branch to 0 as the branch is to
            an absolute address of 0.

            Now we save the exception handler address for the original generated function and
            link the exception cases for these by-val stubs to this handler.

            * bytecode/ByValInfo.h:
            (JSC::ByValInfo::ByValInfo): Added the address of the exception handler we should
            link to.

            * jit/JIT.cpp:
            (JSC::JIT::link): Compute the linked exception handler address and pass it to
            the ByValInfo constructor.
            (JSC::JIT::privateCompileExceptionHandlers): Make sure that we generate the
            exception handler if we have any by-val handlers.

            * jit/JIT.h:
            Added a label for the exception handler.  We'll link this later for the
            by value handlers.

            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::privateCompileGetByValWithCachedId):
            (JSC::JIT::privateCompilePutByValWithCachedId):
            Link exception branches to the exception handler for the main function.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204360. rdar://problem/27991577

    2016-08-10  Mark Lam  <mark.lam@apple.com>

            DFG's flushForTerminal() needs to add PhantomLocals for bytecode live locals.
            https://bugs.webkit.org/show_bug.cgi?id=160755
            <rdar://problem/27488507>

            Reviewed by Filip Pizlo.

            If the DFG sees that an inlined function will result in an OSR exit every time,
            it will treat all downstream blocks as dead.  However, it still needs to keep
            locals that are alive in the bytecode alive for the compiled function so that
            those locals are properly written to the stack by the OSR exit ramp.

            The existing code neglected to do this.  This patch remedies this issue.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::flushDirect):
            (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal):
            (JSC::DFG::ByteCodeParser::phantomLocalDirect):
            (JSC::DFG::ByteCodeParser::flushForTerminal):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203952. rdar://problem/27991571

    2016-07-30  Mark Lam  <mark.lam@apple.com>

            Assertion failure while setting the length of an ArrayClass array.
            https://bugs.webkit.org/show_bug.cgi?id=160381
            <rdar://problem/27328703>

            Reviewed by Filip Pizlo.

            When setting large length values, we're currently treating ArrayClass as a
            ContiguousIndexingType array.  This results in an assertion failure.  This is
            now fixed.

            There are currently only 2 places where we create arrays with indexing type
            ArrayClass: ArrayPrototype and RuntimeArray.  The fix in JSArray:;setLength()
            takes care of ArrayPrototype.

            RuntimeArray already checks for the setting of its length property, and will
            throw a RangeError.  Hence, there's no change is needed for the RuntimeArray.
            Instead, I added some test cases ensure that the check and throw behavior does
            not change without notice.

            * runtime/JSArray.cpp:
            (JSC::JSArray::setLength):
            * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added.
            (toString):
            (assertEqual):
            * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added.
            (toString):
            (assertEqual):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203853. rdar://problem/27991580

    2016-07-28  Mark Lam  <mark.lam@apple.com>

            ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string.
            https://bugs.webkit.org/show_bug.cgi?id=160324
            <rdar://problem/27389572>

            Reviewed by Keith Miller.

            The issue is that errorProtoFuncToString() was using jsNontrivialString() to
            generate the error string even when the name string can be a single character
            string.  This is incorrect.  We should be using jsString() instead.

            * runtime/ErrorPrototype.cpp:
            (JSC::errorProtoFuncToString):
            * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203834. rdar://problem/27991582

    2016-07-28  Mark Lam  <mark.lam@apple.com>

            StringView should have an explicit m_is8Bit field.
            https://bugs.webkit.org/show_bug.cgi?id=160282
            <rdar://problem/27327943>

            Reviewed by Benjamin Poulain.

            * tests/stress/string-joining-long-strings-should-not-crash.js: Added.
            (catch):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203802. rdar://problem/27991569

    2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

            [JSC] Fix a bunch of use-after-free of DFG::Node
            https://bugs.webkit.org/show_bug.cgi?id=160228

            Reviewed by Mark Lam.

            FTL had a few places where we use a node after it has been
            deleted. The dangling pointers come from the SSA liveness information
            kept on the basic blocks.

            This patch fixes the issues I could find and adds liveness invalidation
            to help finding dependencies like these.

            * dfg/DFGBasicBlock.h:
            (JSC::DFG::BasicBlock::SSAData::invalidate):

            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::run):
            Constant folding phase was deleting nodes in the loop over basic blocks.
            The problem is the deleted nodes can be referenced by other blocks.
            When the abstract interpreter was manipulating the abstract values of those
            it was doing so on the dead nodes.

            * dfg/DFGConstantHoistingPhase.cpp:
            Just invalidation. Nothing wrong here since the useless nodes were
            kept live while iterating the blocks.

            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::killBlockAndItsContents):
            (JSC::DFG::Graph::killUnreachableBlocks):
            (JSC::DFG::Graph::invalidateNodeLiveness):

            * dfg/DFGGraph.h:
            * dfg/DFGPlan.cpp:
            (JSC::DFG::Plan::compileInThreadImpl):
            We had a lot of use-after-free in LCIM because we were using the stale
            live nodes deleted by previous phases.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203798. rdar://problem/27991578

    2016-07-27  Keith Miller  <keith_miller@apple.com>

            concatAppendOne should allocate using the indexing type of the array if it cannot merge
            https://bugs.webkit.org/show_bug.cgi?id=160261
            <rdar://problem/27530122>

            Reviewed by Mark Lam.

            Before, if we could not merge the indexing types for copying, we would allocate the
            the array as ArrayWithUndecided. Instead, we should allocate an array with the original
            array's indexing type.

            * runtime/ArrayPrototype.cpp:
            (JSC::concatAppendOne):
            * tests/stress/concat-append-one-with-sparse-array.js: Added.

2016-08-29  Babak Shafiei  <bshafiei@apple.com>

        Merge r204572.

    2016-08-17  Geoffrey Garen  <ggaren@apple.com>

            Fixed a potential bug in MarkedArgumentBuffer.
            https://bugs.webkit.org/show_bug.cgi?id=160948
            <rdar://problem/27889416>

            Reviewed by Oliver Hunt.

            I haven't been able to produce an observable test case after some trying.

            * runtime/ArgList.cpp:
            (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke
            this out from existing code for clarity, but the behavior is the same.

            (JSC::MarkedArgumentBuffer::expandCapacity): Ditto.

            (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow
            path. This is faster than the old linear scan, and I think it might
            avoid cases the old scan could miss.

            * runtime/ArgList.h:
            (JSC::MarkedArgumentBuffer::append): Account for the case where someone
            has called clear() or removeLast().

            (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's
            clearer to test the buffers directly instead of inferring what they
            might be based on capacity.

2016-05-13  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r196490. rdar://problem/26270811

    2016-02-12  Filip Pizlo  <fpizlo@apple.com>

            Fast path in JSObject::defineOwnIndexedProperty() forgets to check for the posibility of a descriptor that doesn't have a value
            https://bugs.webkit.org/show_bug.cgi?id=154175
            rdar://problem/24291497

            Reviewed by Geoffrey Garen.

            * runtime/JSObject.cpp:
            (JSC::JSObject::defineOwnIndexedProperty): Fix the bug.
            * runtime/SparseArrayValueMap.cpp:
            (JSC::SparseArrayValueMap::putEntry): Catch the bug sooner in debug.
            (JSC::SparseArrayValueMap::putDirect):
            * tests/stress/sparse-define-empty-descriptor.js: Added. This used to crash in release.

2016-05-13  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r196240. rdar://problem/26271108

    2016-02-07  Filip Pizlo  <fpizlo@apple.com>

            String.match should defend against matches that would crash the VM
            https://bugs.webkit.org/show_bug.cgi?id=153964
            rdar://problem/24301119

            Reviewed by Saam Barati.

            This fixes a crash in an internal test case.

            * runtime/ArgList.cpp:
            (JSC::MarkedArgumentBuffer::slowAppend): Use best practices to ensure that the size we
                compute makes sense. Crash if it stops making sense, since most users of this API assume
                that they are creating something small enough to fit on the stack.
            * runtime/ArgList.h:
            (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
            (JSC::MarkedArgumentBuffer::size):
            (JSC::MarkedArgumentBuffer::operator new): Deleted. These were ineffective. According to the
                debugger, we were still calling system malloc. So, I changed the code to use fastMalloc()
                directly.
            (JSC::MarkedArgumentBuffer::operator delete): Deleted.
            * runtime/StringPrototype.cpp:
            (JSC::stringProtoFuncMatch): Explicitly defend against absurd sizes. Of course, it's still
                possible to crash the VM on OOME. That's sort of always been the philosophy of JSC - we
                don't guarantee that you'll get a nice-looking error whenever you run out of memory,
                since in a GC'd environment you can't really guarantee those things. But, if you have a
                match that obvious won't fit in memory, then reporting an error is useful in case this is
                a developer experimenting with a buggy regexp.

2016-05-12  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for r200387.

    2016-05-03  Michael Saboff  <msaboff@apple.com>

            Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
            https://bugs.webkit.org/show_bug.cgi?id=157322

            Reviewed by Filip Pizlo.

            Check to see if the source array has changed length before calling fastSlice().
            If it has, take the slow path.

            * runtime/ArrayPrototype.cpp:
            (JSC::arrayProtoFuncSlice):
            (JSC::arrayProtoFuncSplice):
            * tests/stress/regress-157322.js: New test.

2016-05-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r199277. rdar://problem/26228546

    2016-04-09  Saam barati  <sbarati@apple.com>

            Allocation sinking SSA Defs are allowed to have replacements
            https://bugs.webkit.org/show_bug.cgi?id=156444

            Reviewed by Filip Pizlo.

            Consider the following program and the annotations that explain why
            the SSA defs we create in allocation sinking can have replacements.

            function foo(a1) {
                let o1 = {x: 20, y: 50};
                let o2 = {y: 40, o1: o1};
                let o3 = {};

                // We're Defing a new variable here, call it o3_field.
                // o3_field is defing the value that is the result of
                // a GetByOffset that gets eliminated through allocation sinking.
                o3.field = o1.y;

                dontCSE();

                // This control flow is here to not allow the phase to consult
                // its local SSA mapping (which properly handles replacements)
                // for the value of o3_field.
                if (a1) {
                    a1 = true;
                } else {
                    a1 = false;
                }

                // Here, we ask for the reaching def of o3_field, and assert
                // it doesn't have a replacement. It does have a replacement
                // though. The original Def was the GetByOffset. We replaced
                // that GetByOffset with the value of the o1_y variable.
                let value = o3.field;
                assert(value === 50);
            }

            * dfg/DFGObjectAllocationSinkingPhase.cpp:
            * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
            (dontCSE):
            (assert):
            (foo):

2016-05-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r196524. rdar://problem/26228552

    2016-02-12  Filip Pizlo  <fpizlo@apple.com>

            JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX
            https://bugs.webkit.org/show_bug.cgi?id=154201
            rdar://problem/24291387

            Reviewed by Saam Barati.

            I decided against adding a test for this, because it runs for a very long time.

            * runtime/JSObject.cpp:
            (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug.
            * runtime/StringPrototype.cpp:
            (JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have
                hit the above bug, then it would probably manifest as a spin or as swapping.

2016-03-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r198592. rdar://problem/25332806

    2016-03-23  Michael Saboff  <msaboff@apple.com>

            JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls
            https://bugs.webkit.org/show_bug.cgi?id=155776

            Reviewed by Saam Barati.

            Array.join ends up calling toString, possibly on some object.  Since these calls
            could be effectful and could change the array itself, we can't hold the butterfly
            pointer while making effectful calls.  Changed the code to fall back to the general
            case when an effectful toString() call might be made.

            * runtime/ArrayPrototype.cpp:
            (JSC::join):
            * runtime/JSStringJoiner.h:
            (JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful
            toString() calls.
            (JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects.

2016-02-26  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for rdar://problem/24826901.

2016-02-12  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for rdar://problem/24626412.

    2016-02-12  Brent Fulgham  <bfulgham@apple.com>

            [Win] Correct internal branch build failure.
            <rdar://problem/24626412>

            Work around some C++11 compiler limitations in VS2013. The new code
            brought into this branch from trunk included some things that the
            older compiler used on this branch does not support.

            * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Correct
            project file.
            * inspector/InspectorBackendDispatcher.cpp:
            (Inspector::castToInteger): Restored to work around compiler bug.
            (Inspector::castToNumber): Ditto.
            (Inspector::asString): Ditto.
            (Inspector::asBoolean): Ditto.
            (Inspector::asObject): Ditto.
            (Inspector::asArray): Ditto.
            (Inspector::asValue): Ditto.
            (Inspector::BackendDispatcher::getInteger): Add VS2013 workaround.
            (Inspector::BackendDispatcher::getString): Ditto.
            (Inspector::BackendDispatcher::getBoolean): Ditto.
            (Inspector::BackendDispatcher::getObject): Ditto.
            (Inspector::BackendDispatcher::getArray): Ditto.
            (Inspector::BackendDispatcher::getValue): Ditto.

2016-02-10  Babak Shafiei  <bshafiei@apple.com>

        Merge r196179.

    2016-02-05  Filip Pizlo  <fpizlo@apple.com>

            Arrayify for a typed array shouldn't create a monster
            https://bugs.webkit.org/show_bug.cgi?id=153908
            rdar://problem/24290639

            Reviewed by Mark Lam.

            Previously if you convinced the DFG to emit an Arrayify to ArrayStorage and then gave it a
            typed array, you'd corrupt the object.

            * runtime/JSArrayBufferView.cpp:
            (WTF::printInternal):
            * runtime/JSArrayBufferView.h:
            * runtime/JSGenericTypedArrayViewInlines.h:
            (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
            (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
            * runtime/JSObject.cpp:
            (JSC::JSObject::copyButterfly):
            (JSC::JSObject::enterDictionaryIndexingMode):
            (JSC::JSObject::ensureInt32Slow):
            (JSC::JSObject::ensureDoubleSlow):
            (JSC::JSObject::ensureContiguousSlow):
            (JSC::JSObject::ensureArrayStorageSlow):
            (JSC::JSObject::growOutOfLineStorage):
            (JSC::getBoundSlotBaseFunctionForGetterSetter):
            * runtime/Structure.h:
            * tests/stress/arrayify-array-storage-typed-array.js: Added. This test failed.
            * tests/stress/arrayify-int32-typed-array.js: Added. This test case already had other protections, but we beefed them up.

2016-01-29  Babak Shafiei  <bshafiei@apple.com>

        Merge r194479.

    2016-01-01  Jeff Miller  <jeffm@apple.com>

            Update user-visible copyright strings to include 2016
            https://bugs.webkit.org/show_bug.cgi?id=152531

            Reviewed by Alexey Proskuryakov.

            * Info.plist:

2016-01-29  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for rdar://problem/23968717.

    2016-01-28  Saam barati  <sbarati@apple.com>

            Inspector should remove cached code when it recompiles due to the Type Profiler being disabled.

            Keeping around cached code is a mistake because we then
            generate code that depends on the VM having a TypeProfiler
            when it doesn't. Note that VM::discardAllCode does exactly
            what we want.

            * inspector/agents/InspectorRuntimeAgent.cpp:
            (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
            (Inspector::recompileAllJSFunctionsForTypeProfiling):
            (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
            (Inspector::TypeRecompiler::visit): Deleted.
            (Inspector::TypeRecompiler::operator()): Deleted.

2016-01-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r194559. rdar://problem/24269083

    2016-01-04  Tim Horton  <timothy_horton@apple.com>

            Turn on gesture events when building for Yosemite
            https://bugs.webkit.org/show_bug.cgi?id=152704
            rdar://problem/24042472

            Reviewed by Anders Carlsson.

            * Configurations/FeatureDefines.xcconfig:

2016-01-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r193782. rdar://problem/24358367

    2015-12-08  Filip Pizlo  <fpizlo@apple.com>

            DFG::UnificationPhase should merge isProfitableToUnbox, since this may have been set in ByteCodeParser
            https://bugs.webkit.org/show_bug.cgi?id=152011
            rdar://problem/23777875

            Reviewed by Michael Saboff.

            Previously UnificationPhase did not merge this because we used to only set this in FixupPhase, which runs after unification. But now
            ByteCodeParser may set isProfitableToUnbox as part of how it handles the ArgumentCount of an inlined varargs call, so UnificationPhase
            needs to merge it after unifying.

            Also changed the order of unification since this makes the bug more obvious and easier to test.

            * dfg/DFGUnificationPhase.cpp:
            (JSC::DFG::UnificationPhase::run):
            * tests/stress/varargs-with-unused-count.js: Added.

2016-01-13  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r193939. rdar://problem/24154418

    2015-12-10  Daniel Bates  <dabates@apple.com>

            [CSP] eval() is not blocked for stringified literals
            https://bugs.webkit.org/show_bug.cgi?id=152158
            <rdar://problem/15775625>

            Reviewed by Saam Barati.

            Fixes an issue where stringified literals can be eval()ed despite being disallowed by
            Content Security Policy of the page.

            * interpreter/Interpreter.cpp:
            (JSC::eval): Throw a JavaScript EvalError exception if eval() is disallowed for the page
            and return undefined.
            * runtime/JSGlobalObjectFunctions.cpp:
            (JSC::globalFuncEval): Ditto.

2016-01-12  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r194704. rdar://problem/24043057

    2016-01-06  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: CRASH Attempting to pause on CSP violation not inside of script
            https://bugs.webkit.org/show_bug.cgi?id=152825
            <rdar://problem/24021276>

            Reviewed by Timothy Hatcher.

            * debugger/Debugger.cpp:
            (JSC::Debugger::breakProgram):
            We cannot pause if we are not evaluating JavaScript, so bail.

2016-01-12  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r194908. rdar://problem/24101253

    2016-01-11  Matthew Hanson  <matthew_hanson@apple.com>

            Merge r192186. rdar://problem/24101174

        2015-11-09  Joseph Pecoraro  <pecoraro@apple.com>

                Web Inspector: $0 stops working after navigating to a different domain
                https://bugs.webkit.org/show_bug.cgi?id=147962

                Reviewed by Brian Burg.

                Extract the per-GlobalObject cache of JSValue wrappers for
                InjectedScriptHost objects to be reused by WebCore for its
                CommandLineAPIHost objects injected into multiple contexts.

                * CMakeLists.txt:
                * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
                * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
                * JavaScriptCore.xcodeproj/project.pbxproj:
                Add new files.

                * inspector/PerGlobalObjectWrapperWorld.h:
                * inspector/PerGlobalObjectWrapperWorld.cpp:
                (Inspector::PerGlobalObjectWrapperWorld::getWrapper):
                (Inspector::PerGlobalObjectWrapperWorld::addWrapper):
                (Inspector::PerGlobalObjectWrapperWorld::clearAllWrappers):
                Hold a bunch of per-global-object wrappers for an object
                that will outlive the global object. This inspector does this
                for host objects that it exposes into scripts it injects into
                each execution context created by the page.

                * inspector/InjectedScriptHost.cpp:
                (Inspector::InjectedScriptHost::wrapper):
                (Inspector::InjectedScriptHost::clearAllWrappers):
                (Inspector::InjectedScriptHost::jsWrapper): Deleted.
                (Inspector::clearWrapperFromValue): Deleted.
                (Inspector::InjectedScriptHost::clearWrapper): Deleted.
                Extract and simplify the Per-GlobalObject wrapping into a class.
                Simplify object construction as well.

                * inspector/InjectedScriptHost.h:
                * inspector/InjectedScriptManager.cpp:
                (Inspector::InjectedScriptManager::createInjectedScript):
                (Inspector::InjectedScriptManager::discardInjectedScripts):
                Make discarding virtual so subclasses may also discard injected scripts.

                * inspector/JSInjectedScriptHost.cpp:
                (Inspector::JSInjectedScriptHost::JSInjectedScriptHost):
                (Inspector::JSInjectedScriptHost::releaseImpl): Deleted.
                (Inspector::JSInjectedScriptHost::~JSInjectedScriptHost): Deleted.
                (Inspector::toJS): Deleted.
                (Inspector::toJSInjectedScriptHost): Deleted.
                * inspector/JSInjectedScriptHost.h:
                (Inspector::JSInjectedScriptHost::create):
                (Inspector::JSInjectedScriptHost::impl):
                Update this code originally copied from older generated bindings to
                be more like new generated bindings and remove some now unused code.

2015-12-17  Babak Shafiei  <bshafiei@apple.com>

        Merge r191343.

    2015-10-20  Tim Horton  <timothy_horton@apple.com>

            Try to fix the build by disabling MAC_GESTURE_EVENTS on 10.9 and 10.10

            * Configurations/FeatureDefines.xcconfig:

2015-12-17  Babak Shafiei  <bshafiei@apple.com>

        Merge r191305.

    2015-10-19  Tim Horton  <timothy_horton@apple.com>

            Try to fix the iOS build

            * Configurations/FeatureDefines.xcconfig:

2015-12-16  Babak Shafiei  <bshafiei@apple.com>

        Merge r191299.

    2015-10-19  Tim Horton  <timothy_horton@apple.com>

            Add magnify and rotate gesture event support for Mac
            https://bugs.webkit.org/show_bug.cgi?id=150179
            <rdar://problem/8036240>

            Reviewed by Darin Adler.

            * Configurations/FeatureDefines.xcconfig:
            New feature flag.

2015-12-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r193480. rdar://problem/23849785

    2015-12-04  Filip Pizlo  <fpizlo@apple.com>

            Having a bad time has a really awful time when it runs at the same time as the JIT
            https://bugs.webkit.org/show_bug.cgi?id=151882
            rdar://problem/23547038

            Unreviewed, really adding the test this time.

            * tests/stress/ftl-has-a-bad-time.js: Added.
            (foo):

2015-12-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r193470. rdar://problem/23849785

    2015-12-04  Filip Pizlo  <fpizlo@apple.com>

            Having a bad time has a really awful time when it runs at the same time as the JIT
            https://bugs.webkit.org/show_bug.cgi?id=151882
            rdar://problem/23547038

            Reviewed by Geoffrey Garen.

            The DFG's use of watchpoints for havingABadTime goes back a long time. We introduced this feature
            when we first introduced watchpoints. That left it open to a lot of bitrot. On top of that, this
            code doesn't get tested much because having a bad time is not something that is really supposed to
            happen.

            Well, now I've got reports that it does happen - or at least, we know that it is because of
            crashes in an assertion that could only be triggered if a bad time was had. In the meantime, we
            added two new features without adequately testing havingABadTime: concurrent JIT and FTL.
            Concurrency means that we have to worry about the havingABadTime watchpoint triggering during
            compilation. FTL means that we have new code and new optimizations that needs to deal with this
            feature correctly.

            The bug can arise via race condition or just goofy profiling. As in the newly added test, we could
            first profile an allocation thinking that it will allocate sane arrays. Then we might have a bad
            time, and then compile that function with the FTL. The ByteCodeParser will represent the
            allocation with a NewArray node that has a sane indexingType(). But when we go to lower the Node,
            we observe that the Structure* that the JSGlobalObject tells us to use has a different indexing
            type. This is a feature of havingABadTime that the DFG knew about, but the FTL didn't. The FTL
            didn't know about it because we didn't have adequate tests, and this code rarely gets triggered in
            the wild. So, the FTL had a silly assertion that the indexing types match. They absolutely don't
            have to match.

            There is another bug, a race condition, that remains even if we remove the bad assertion. We set
            the havingABadTime watchpoint late in compilation, and we do it based on whether the watchpoint is
            still OK. This means that we could parse a function before we have a bad time and then do
            optimizations (for example in AbstractInterpreter) like proving that the structure set associated
            with the value returned by the NewArray is the one with a sane indexing type. Then, after those
            optimizations have already been done, we will go to set the watchpoint. But just as we are doing
            this, we could haveABadTime on the main thread. Currently this sort of almost works because
            having a bad time requires doing a GC, and we can't GC until the watchpoint collection phase. But
            that feels too fragile. So, this phase moves the setting of the watchpoint to the FixupPhase. This
            is consistent with our long-term goal of removing the WatchpointCollectionPhase. Moving this to
            FixupPhase means that we set the watchpoint before doing any optimizations. So, if having a bad
            time happens before the FixupPhase then all optimizations will agree that we're having a bad time
            and so everything is fine; if we have a bad time after FixupPhase then we will cancel the
            compilation anyway.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            (JSC::DFG::FixupPhase::watchHavingABadTime):
            (JSC::DFG::FixupPhase::createToString):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::hasIndexingType):
            (JSC::DFG::Node::indexingType):
            * dfg/DFGWatchpointCollectionPhase.cpp:
            (JSC::DFG::WatchpointCollectionPhase::handle):
            * ftl/FTLLowerDFGToLLVM.cpp:
            (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
            (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
            * tests/stress/ftl-has-a-bad-time.js: Added.

2015-12-04  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r192190. rdar://problem/23732407

    2015-11-09  Saam barati  <sbarati@apple.com>

            DFG::PutStackSinkingPhase should not treat the stack variables written by LoadVarargs/ForwardVarargs as being live
            https://bugs.webkit.org/show_bug.cgi?id=145295

            Reviewed by Filip Pizlo.

            This patch fixes PutStackSinkingPhase to no longer escape the stack
            locations that LoadVarargs and ForwardVarargs write to. We used
            to consider sinking PutStacks right before a LoadVarargs/ForwardVarargs
            because we considered them uses of such stack locations. They aren't
            uses of those stack locations, they unconditionally write to those
            stack locations. Sinking PutStacks to these nodes was not needed before,
            but seemed mostly innocent. But I ran into a problem with this while implementing
            FTL try/catch where we would end up having to generate a value for a sunken PutStack
            right before a LoadVarargs. This would cause us to issue a GetStack that loaded garbage that
            was then forwarded into a Phi that was used as the source as the PutStack. This caused the
            abstract interpreter to confuse itself on type information for the garbage GetStack
            that was fed into the Phi, which would cause the abstract interpreter to then claim
            that the basic block with the PutStack in it would never be reached. This isn't true, the
            block would indeed be reached. The solution here is to be more precise about the
            liveness of locals w.r.t LoadVarargs and ForwardVarargs.

            * dfg/DFGPreciseLocalClobberize.h:
            (JSC::DFG::PreciseLocalClobberizeAdaptor::PreciseLocalClobberizeAdaptor):
            (JSC::DFG::PreciseLocalClobberizeAdaptor::write):
            * dfg/DFGPutStackSinkingPhase.cpp:
            * dfg/DFGSSACalculator.h:

2015-12-04  Timothy Hatcher  <timothy@apple.com>

        Merge r192391. rdar://problem/23221163

    2015-11-12  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Reduce list of saved console messages
            https://bugs.webkit.org/show_bug.cgi?id=151225

            Reviewed by Geoffrey Garen.

            Inspector saves messages so that when an inspector frontend opens it can report
            these messages to the frontend. However we were saving a rather large list of
            1000 messages. Most pages do not produce a large number of console messages.
            However pages that live for a long time can generate many errors over time,
            especially periodic engine issues such as cross-origin access errors. This could
            result in a lot of wasted memory for console messages that may never be used.

            Likewise when an inspector first open sending all 1000 messages to the frontend
            results in a poor experience.

            Lets reduce the list of saved messages. Developer will still be able to see
            all messages as long as they have Web Inspector open at the time the messages
            are generated.

            * inspector/agents/InspectorConsoleAgent.cpp:
            Reduce the list from 1000 to 100. Also, when expiring
            messages from this list, chunk in 10s instead of 100s.

2015-12-04  Timothy Hatcher  <timothy@apple.com>

        Merge r191397. rdar://problem/23221163

    2015-10-21  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Array previews with Symbol objects have too few preview values
            https://bugs.webkit.org/show_bug.cgi?id=150404

            Reviewed by Timothy Hatcher.

            * inspector/InjectedScriptSource.js:
            (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
            We should be continuing inside this loop not returning.

2015-12-04  Timothy Hatcher  <timothy@apple.com>

        Merge r188976. rdar://problem/23221163

    2015-08-26  Brian Burg  <bburg@apple.com>

            Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
            https://bugs.webkit.org/show_bug.cgi?id=148480

            Reviewed by Joseph Pecoraro.

            I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
            not hold if dispatching a backend command while debugger is paused. I will remove the assertion
            and add proper scoping for all dispatch() branches.

            No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.

            * inspector/InspectorBackendDispatcher.cpp:
            (Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.

2015-12-04  Timothy Hatcher  <timothy@apple.com>

        Merge r188656. rdar://problem/23221163

    2015-08-19  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Unexpected node preview format for an element with newlines in className attribute
            https://bugs.webkit.org/show_bug.cgi?id=148192

            Reviewed by Brian Burg.

            * inspector/InjectedScriptSource.js:
            (InjectedScript.prototype._nodePreview):
            Replace whitespace blocks with single spaces to produce a simpler class string for previews.

2015-12-04  Timothy Hatcher  <timothy@apple.com>

        Merge r187897. rdar://problem/23221163

    2015-08-04  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Object previews for SVG elements shows SVGAnimatedString instead of text
            https://bugs.webkit.org/show_bug.cgi?id=147328

            Reviewed by Timothy Hatcher.

            * inspector/InjectedScriptSource.js:
            Use classList and classList.toString instead of className.

2015-12-03  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r188530. rdar://problem/23732374

    2015-08-17  Simon Fraser  <simon.fraser@apple.com>

            will-change should sometimes trigger compositing
            https://bugs.webkit.org/show_bug.cgi?id=148072

            Reviewed by Tim Horton.

            Include will-change as a reason for compositing.

            * inspector/protocol/LayerTree.json:

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r191967. rdar://problem/23221163

    2015-11-03  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Handle or Remove ParseHTML Timeline Event Records
            https://bugs.webkit.org/show_bug.cgi?id=150689

            Reviewed by Timothy Hatcher.

            * inspector/protocol/Timeline.json:

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r191692. rdar://problem/23221163

    2015-10-28  Timothy Hatcher  <timothy@apple.com>

            Web Inspector: jsmin.py mistakenly removes whitespace from template literal strings
            https://bugs.webkit.org/show_bug.cgi?id=148728

            Reviewed by Joseph Pecoraro.

            * Scripts/jsmin.py:
            (JavascriptMinify.minify): Make backtick a quoting character.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r191651. rdar://problem/23221163

    2015-10-27  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Remove Timeline MarkDOMContent and MarkLoad, data is already available
            https://bugs.webkit.org/show_bug.cgi?id=150615

            Reviewed by Timothy Hatcher.

            * inspector/protocol/Timeline.json:

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r191355. rdar://problem/23221163

    2015-10-20  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
            https://bugs.webkit.org/show_bug.cgi?id=150096

            Reviewed by Geoffrey Garen.

            * inspector/ContentSearchUtilities.cpp:
            (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
            (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
            (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
            * inspector/ContentSearchUtilities.h:
            No longer need to search script content.

            * inspector/ScriptDebugServer.cpp:
            (Inspector::ScriptDebugServer::dispatchDidParseSource):
            Carry over the sourceURL and sourceMappingURL from the SourceProvider.

            * inspector/agents/InspectorDebuggerAgent.cpp:
            (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
            (Inspector::InspectorDebuggerAgent::didParseSource):
            No longer do content searching.

            * parser/Lexer.cpp:
            (JSC::Lexer<T>::setCode):
            (JSC::Lexer<T>::skipWhitespace):
            (JSC::Lexer<T>::parseCommentDirective):
            (JSC::Lexer<T>::parseCommentDirectiveValue):
            (JSC::Lexer<T>::consume):
            (JSC::Lexer<T>::lex):
            * parser/Lexer.h:
            (JSC::Lexer::sourceURL):
            (JSC::Lexer::sourceMappingURL):
            (JSC::Lexer::sourceProvider): Deleted.
            Give lexer the ability to detect script comment directives.
            This just consumes characters in single line comments and
            ultimately sets the sourceURL or sourceMappingURL found.

            * parser/Parser.h:
            (JSC::Parser<LexerType>::parse):
            * parser/SourceProvider.h:
            (JSC::SourceProvider::url):
            (JSC::SourceProvider::sourceURL):
            (JSC::SourceProvider::sourceMappingURL):
            (JSC::SourceProvider::setSourceURL):
            (JSC::SourceProvider::setSourceMappingURL):
            After parsing a script, update the Source Provider with the
            value of directives that may have been found in the script.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r190542. rdar://problem/23221163

    2015-10-02  Matt Baker  <mattbaker@apple.com>

            Web Inspector: Add breakpoint option to ignore n times before stopping
            https://bugs.webkit.org/show_bug.cgi?id=147664

            Reviewed by Timothy Hatcher.

            * debugger/Breakpoint.h:
            (JSC::Breakpoint::Breakpoint):
            Added ignoreCount and hitCount fields. Cleaned up initializers.

            * debugger/Debugger.cpp:
            (JSC::Debugger::hasBreakpoint):
            If a breakpoint matches the current text position, increment breakpoint hit count and
            compare with ignore count before testing the breakpoint condition.

            * inspector/ScriptBreakpoint.h:
            (Inspector::ScriptBreakpoint::ScriptBreakpoint):
            Added ignoreCount field. Cleaned up initializers.

            * inspector/ScriptDebugServer.cpp:
            (Inspector::ScriptDebugServer::setBreakpoint):
            Added ignoreCount field.

            * inspector/agents/InspectorDebuggerAgent.cpp:
            (Inspector::buildObjectForBreakpointCookie):
            (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
            (Inspector::InspectorDebuggerAgent::setBreakpoint):
            (Inspector::InspectorDebuggerAgent::continueToLocation):
            (Inspector::InspectorDebuggerAgent::didParseSource):
            Plumbing for ignoreCount property.

            * inspector/protocol/Debugger.json:
            Added optional ignoreCount property to BreakpointOptions object.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r190146. rdar://problem/23221163

    2015-09-22  Saam barati  <sbarati@apple.com>

            Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
            https://bugs.webkit.org/show_bug.cgi?id=143171

            Reviewed by Joseph Pecoraro.

            We now need to take into account TypeProfilerSearchDescriptor when
            hashing results for type profiler queries. Before, we've gotten
            away with not doing this because before we would never have a text
            collision between a return type text offset and a normal expression text
            offset. But, with arrow functions, we will have collisions when
            the arrow function doesn't have parens around its single parameter.
            I.e: "param => { ... };"

            * runtime/TypeProfiler.cpp:
            (JSC::TypeProfiler::findLocation):
            * runtime/TypeProfiler.h:
            (JSC::QueryKey::QueryKey):
            (JSC::QueryKey::isHashTableDeletedValue):
            (JSC::QueryKey::operator==):
            (JSC::QueryKey::hash):
            * tests/typeProfiler/arrow-functions.js: Added.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r189415. rdar://problem/23221163

    2015-09-04  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Test Runtime.saveResult and $n values
            https://bugs.webkit.org/show_bug.cgi?id=148837

            Reviewed by Timothy Hatcher.

            * inspector/InjectedScriptSource.js:
            (InjectedScript.prototype._evaluateOn):
            We don't need to be in the console object group to put the value
            in the saved results list. That strong reference will ensure $n
            values are always alive even if other object groups were used
            when creating and subsequently released.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r189373. rdar://problem/23221163

    2015-09-04  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Expand Console domain test coverage
            https://bugs.webkit.org/show_bug.cgi?id=148740

            Reviewed by Brian Burg.

            * inspector/protocol/Console.json:
            Update the description of this command now that it only
            manipulates $0, and not $1, $2, .. $n.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r189104. rdar://problem/23221163

    2015-08-28  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Separate creating a style sheet from adding a new rule in the protocol
            https://bugs.webkit.org/show_bug.cgi?id=148502

            Reviewed by Timothy Hatcher.

            * inspector/protocol/CSS.json:
            Add CSS.createStyleSheet. Modify CSS.addRule.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r189002. rdar://problem/23221163

    2015-08-26  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Implement tracking of active stylesheets in the frontend
            https://bugs.webkit.org/show_bug.cgi?id=105828

            Reviewed by Timothy Hatcher.

            * inspector/protocol/CSS.json:
            Add new events for when a StyleSheet is added or removed.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r188965. rdar://problem/23221163

    2015-08-25  Brian Burg  <bburg@apple.com>

            Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
            https://bugs.webkit.org/show_bug.cgi?id=146466

            Reviewed by Joseph Pecoraro.

            Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
            of objects in the common case when no protocol errors happen. This is done by saving the
            current id of each request as it is being processed by the backend dispatcher, and tagging any
            subsequent errors with that id. This also means we don't have to thread the requestId except
            in the async command code path.

            This patch also lifts some common code shared between all generated backend command
            implementatations into the per-domain dispatch method instead. This reduces generated code size.

            To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
            Requests can be handled synchronously or asynchronously (triggered via the 'async' property).

            No new tests, covered by existing protocol tests.

            * inspector/InspectorBackendDispatcher.cpp:
            (Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
            success and failure.

            (Inspector::BackendDispatcher::CallbackBase::sendFailure):
            (Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
            (Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
            No need to manually thread the requestId to all reportProtocolError calls.

            (Inspector::BackendDispatcher::hasProtocolErrors): Added.
            (Inspector::BackendDispatcher::sendResponse):
            (Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
            Always send a 'data' member with all of the errors, even if there's just one. We might want to add
            more information about errors later.

            (Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
            (Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
            the type conversion methods. Use std::function types instead of function pointer types.

            (Inspector::castToInteger): Added.
            (Inspector::castToNumber): Added.
            (Inspector::BackendDispatcher::getInteger):
            (Inspector::BackendDispatcher::getDouble):
            (Inspector::BackendDispatcher::getString):
            (Inspector::BackendDispatcher::getBoolean):
            (Inspector::BackendDispatcher::getObject):
            (Inspector::BackendDispatcher::getArray):
            (Inspector::BackendDispatcher::getValue):
            (Inspector::getPropertyValue): Deleted.
            (Inspector::AsMethodBridges::asInteger): Deleted.
            (Inspector::AsMethodBridges::asDouble): Deleted.
            (Inspector::AsMethodBridges::asString): Deleted.
            (Inspector::AsMethodBridges::asBoolean): Deleted.
            (Inspector::AsMethodBridges::asObject): Deleted.
            (Inspector::AsMethodBridges::asArray): Deleted.
            (Inspector::AsMethodBridges::asValue): Deleted.
            * inspector/InspectorBackendDispatcher.h:
            * inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
            Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
            to decide whether to abort the dispatch or not, rather than allocating our own errors array.

            * inspector/scripts/codegen/cpp_generator_templates.py:
            (void):
            * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
            since parameters are now being passed rather than the message object. Some commands do not require parameters.
            * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
            (CppBackendDispatcherImplementationGenerator.generate_output):
            (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
            (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
            * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
            (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
            * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
            (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
            (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
            * inspector/scripts/codegen/objc_generator_templates.py:

            Rebaseline some protocol generator tests.
            * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
            * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
            * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
            * inspector/scripts/tests/expected/enum-values.json-result:
            * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
            * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
            * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
            * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
            * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
            * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
            * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
            * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
            * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r188897. rdar://problem/23221163

    2015-08-24  Brian Burg  <bburg@apple.com>

            Web Inspector: add protocol test for existing error handling performed by the backend
            https://bugs.webkit.org/show_bug.cgi?id=147097

            Reviewed by Joseph Pecoraro.

            A new test revealed that the protocol "method" parameter was being parsed in a naive way.
            Rewrite it to use String::split and improve error checking to avoid failing later.

            * inspector/InspectorBackendDispatcher.cpp:
            (Inspector::BackendDispatcher::dispatch):

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r188631. rdar://problem/23221163

    2015-08-18  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Links for rules in <style> are incorrect, do not account for <style> offset in the document
            https://bugs.webkit.org/show_bug.cgi?id=148141

            Reviewed by Brian Burg.

            * inspector/protocol/CSS.json:
            Extend StyleSheetHeader to include start offset information and a bit
            for whether or not this was an inline style tag created by the parser.
            These match additions to Blink's protocol.

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r188549. rdar://problem/23221163

    2015-08-17  Saam barati  <sbarati@apple.com>

            Web Inspector: Type profiler return types aren't showing up
            https://bugs.webkit.org/show_bug.cgi?id=147348

            Reviewed by Brian Burg.

            Bug #145995 changed the starting offset of a function to
            be the open parenthesis of the function's parameter list.
            This broke JSC's type profiler protocol of communicating
            return types of a function to the web inspector. This
            is now fixed. The text offset used in the protocol is now
            the first letter of the function/get/set/method name.
            So "f" in "function a() {}", "s" in "set foo(){}", etc.

            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::CodeBlock):
            * jsc.cpp:
            (functionReturnTypeFor):

2015-12-02  Timothy Hatcher  <timothy@apple.com>

        Merge r188403. rdar://problem/23221163

    2015-08-13  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: A {Map, WeakMap, Set, WeakSet} object contains itself will hang the console
            https://bugs.webkit.org/show_bug.cgi?id=147966

            Reviewed by Timothy Hatcher.

            * inspector/InjectedScriptSource.js:
            (InjectedScript.prototype._initialPreview):
            Renamed to initial preview. This is not a complete preview for
            this object, and it needs some processing in order to be a
            complete accurate preview.

            (InjectedScript.RemoteObject.prototype._emptyPreview):
            This attempts to be an accurate empty preview for the given object.
            For types with entries, it adds an empty entries list and updates
            the overflow and lossless properties.

            (InjectedScript.RemoteObject.prototype._createObjectPreviewForValue):
            Take a generatePreview parameter to generate a full preview or empty preview.

            (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
            (InjectedScript.RemoteObject.prototype._appendEntryPreviews):
            (InjectedScript.RemoteObject.prototype._isPreviewableObject):
            Take care to avoid cycles.

2015-12-01  Timothy Hatcher  <timothy@apple.com>

        Merge r187496. rdar://problem/23221163

    2015-07-28  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Show Pseudo Elements in DOM Tree
            https://bugs.webkit.org/show_bug.cgi?id=139612

            Reviewed by Timothy Hatcher.

            * inspector/protocol/DOM.json:
            Add new properties to DOMNode if it is a pseudo element or if it has
            pseudo element children. Add new events for if a pseudo element is
            added or removed dynamically to an existing DOMNode.

2015-12-01  Timothy Hatcher  <timothy@apple.com>

        Merge r187249. rdar://problem/23221163

    2015-07-23  Devin Rousso  <drousso@apple.com>

            Web Inspector: Add a function to CSSCompletions to get a list of supported system fonts
            https://bugs.webkit.org/show_bug.cgi?id=147009

            Reviewed by Joseph Pecoraro.

            * inspector/protocol/CSS.json: Added getSupportedSystemFontFamilyNames function.

2015-12-01  Timothy Hatcher  <timothy@apple.com>

        Merge r187211. rdar://problem/23221163

    2015-07-22  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Timeline should immediately start moving play head when starting a new recording
            https://bugs.webkit.org/show_bug.cgi?id=147210

            Reviewed by Timothy Hatcher.

            * inspector/protocol/Timeline.json:
            Add timestamps to recordingStarted and recordingStopped events.

2015-10-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r191395. rdar://problem/22847057

    2015-10-21  Filip Pizlo  <fpizlo@apple.com>

            Failures in PutStackSinkingPhase should be less severe
            https://bugs.webkit.org/show_bug.cgi?id=150400

            Reviewed by Geoffrey Garen.

            Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
            PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.

            * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
            (JSC::DFG::Plan::compileInThreadImpl):
            * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
            * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.

2015-10-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r187510. rdar://problem/22847057

    2015-07-28  Filip Pizlo  <fpizlo@apple.com>

            DFG::PutStackSinkingPhase should be more aggressive about its "no GetStack until put" rule
            https://bugs.webkit.org/show_bug.cgi?id=147371

            Reviewed by Mark Lam.

            Two fixes:

            - Make ConflictingFlush really mean that you can't load from the stack slot. This means not
              using ConflictingFlush for arguments.

            - Assert that a GetStack never sees ConflictingFlush.

            * dfg/DFGPutStackSinkingPhase.cpp:

2015-10-26  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r191530. rdar://problem/23206864

    2015-10-23  Michael Saboff  <msaboff@apple.com>

            REGRESSION (r179357-r179359): WebContent Crash using AOL Mail @ com.apple.JavascriptCore JSC::linkPolymorphicCall(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CallVariant, JSC::RegisterPreservationMode) + 1584
            https://bugs.webkit.org/show_bug.cgi?id=150513

            Reviewed by Saam Barati.

            Add check in linkPolymorphicCall() to make sure we have a CodeBlock for the newly added variant.
            If not, we turn the call into a virtual call.

            The bug was caused by a stack overflow when preparing the function for execution.  This properly
            threw an exception, however linkPolymorphicCall() didn't check for this error case.

            Added a new test function "failNextNewCodeBlock()" to test tools to simplify the testing.

            * API/JSCTestRunnerUtils.cpp:
            (JSC::failNextNewCodeBlock):
            (JSC::numberOfDFGCompiles):
            * API/JSCTestRunnerUtils.h:
            * jit/Repatch.cpp:
            (JSC::linkPolymorphicCall):
            * jsc.cpp:
            (GlobalObject::finishCreation):
            (functionTransferArrayBuffer):
            (functionFailNextNewCodeBlock):
            (functionQuit):
            * runtime/Executable.cpp:
            (JSC::ScriptExecutable::prepareForExecutionImpl):
            * runtime/TestRunnerUtils.cpp:
            (JSC::optimizeNextInvocation):
            (JSC::failNextNewCodeBlock):
            (JSC::numberOfDFGCompiles):
            * runtime/TestRunnerUtils.h:
            * runtime/VM.h:
            (JSC::VM::setFailNextNewCodeBlock):
            (JSC::VM::getAndClearFailNextNewCodeBlock):
            (JSC::VM::stackPointerAtVMEntry):

2015-10-22  Matthew Hanson  <matthew_hanson@apple.com>

        Rollout r191395. rdar://problem/22847057

    2015-10-21  Filip Pizlo  <fpizlo@apple.com>

            Failures in PutStackSinkingPhase should be less severe
            https://bugs.webkit.org/show_bug.cgi?id=150400

            Reviewed by Geoffrey Garen.

            Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
            PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.

            * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
            (JSC::DFG::Plan::compileInThreadImpl):
            * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
            * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.

2015-10-22  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r191395. rdar://problem/22847057

    2015-10-21  Filip Pizlo  <fpizlo@apple.com>

            Failures in PutStackSinkingPhase should be less severe
            https://bugs.webkit.org/show_bug.cgi?id=150400

            Reviewed by Geoffrey Garen.

            Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
            PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.

            * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
            (JSC::DFG::Plan::compileInThreadImpl):
            * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
            * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.

2015-10-22  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r191364. rdar://problem/22862879

    2015-10-20  Mark Lam  <mark.lam@apple.com>

            YarrPatternConstructor::containsCapturingTerms() should not assume that its terms.size() is greater than 0.
            https://bugs.webkit.org/show_bug.cgi?id=150372

            Reviewed by Geoffrey Garen.

            * yarr/YarrPattern.cpp:
            (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
            (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
            (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
            (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):

2015-10-13  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r189834. rdar://problem/22801966

    2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Paused Debugger prevents page reload
            https://bugs.webkit.org/show_bug.cgi?id=148174

            Reviewed by Brian Burg.

            * debugger/Debugger.h:
            (JSC::Debugger::suppressAllPauses):
            (JSC::Debugger::setSuppressAllPauses):
            * debugger/Debugger.cpp:
            (JSC::Debugger::Debugger):
            (JSC::Debugger::pauseIfNeeded):
            * inspector/agents/InspectorDebuggerAgent.h:
            * inspector/agents/InspectorDebuggerAgent.cpp:
            (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
            Provide a way to suppress pauses.

2015-10-08  Lucas Forschler  <lforschler@apple.com>

        Merge r189454. rdar://problem/22802036

    2015-09-06  Mark Lam  <mark.lam@apple.com>

            StackOverflow stack unwinding should stop at native frames.
            https://bugs.webkit.org/show_bug.cgi?id=148749

            Reviewed by Michael Saboff.

            In the present code, after ping-pong'ing back and forth between native and JS
            code a few times, if we have a stack overflow on re-entry into the VM to run
            JS code's whose stack frame would overflow the JS stack, the code will end up
            unwinding past the native function that is making the call to re-enter the VM.
            As a result, any clean up code (e.g. destructors for stack variables) in the
            skipped native function frame (and its chain of native function callers) will
            not be called.

            This patch is based on the Michael Saboff's fix of this issue landed on the
            jsc-tailcall branch: http://trac.webkit.org/changeset/188555

            We now check for the case where there are no JS frames to unwind since the
            last native frame, and treat the exception as an unhandled exception.  The
            native function is responsible for further propagating the exception if needed.

            Other supporting work:
            1. Remove vm->vmEntryFrameForThrow.  It should always be the same as
               vm->topVMEntryFrame.
            2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
               helper function instead of rolling its own.
            3. Added a test that exercises this edge case.  The test should not hang or crash.

            * API/tests/PingPongStackOverflowTest.cpp: Added.
            (PingPongStackOverflowObject_hasInstance):
            (testPingPongStackOverflow):
            * API/tests/PingPongStackOverflowTest.h: Added.
            * API/tests/testapi.c:
            (main):
            * JavaScriptCore.xcodeproj/project.pbxproj:
            * interpreter/CallFrame.h:
            (JSC::ExecState::operator=):
            (JSC::ExecState::callerFrame):
            (JSC::ExecState::callerFrameOrVMEntryFrame):
            (JSC::ExecState::argIndexForRegister):
            (JSC::ExecState::callerFrameAndPC):
            * interpreter/Interpreter.cpp:
            (JSC::UnwindFunctor::UnwindFunctor):
            (JSC::UnwindFunctor::operator()):
            (JSC::Interpreter::unwind):
            * interpreter/Interpreter.h:
            (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
            (JSC::Interpreter::sampler):
            * jit/CCallHelpers.h:
            (JSC::CCallHelpers::jumpToExceptionHandler):
            * jit/JITExceptions.cpp:
            (JSC::genericUnwind):
            * jit/JITExceptions.h:
            * jit/JITOpcodes.cpp:
            (JSC::JIT::emit_op_catch):
            * jit/JITOpcodes32_64.cpp:
            (JSC::JIT::emit_op_catch):
            * jit/JITOperations.cpp:
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:
            * runtime/VM.h:
            (JSC::VM::exceptionOffset):
            (JSC::VM::callFrameForThrowOffset):
            (JSC::VM::vmEntryFrameForThrowOffset): Deleted.
            (JSC::VM::topVMEntryFrameOffset): Deleted.

2015-10-02  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r189460. rdar://problem/22802036

    2015-09-06  Mark Lam  <mark.lam@apple.com>

            Gardening: fix broken Windows build after r189454.

            Not reviewed.

            * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
            * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r189046.

    2015-08-27  Basile Clement  <basile_clement@apple.com>

            REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
            https://bugs.webkit.org/show_bug.cgi?id=148411

            Reviewed by Geoffrey Garen and Filip Pizlo.

            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r188311.

    2015-08-11  Alexey Proskuryakov  <ap@apple.com>

            Make ASan build not depend on asan.xcconfig
            https://bugs.webkit.org/show_bug.cgi?id=147840
            rdar://problem/21093702

            Reviewed by Daniel Bates.

            * dfg/DFGOSREntry.cpp:
            (JSC::DFG::OSREntryData::dump):
            (JSC::DFG::prepareOSREntry):
            * ftl/FTLOSREntry.cpp:
            (JSC::FTL::prepareOSREntry):
            * heap/ConservativeRoots.cpp:
            (JSC::ConservativeRoots::genericAddPointer):
            (JSC::ConservativeRoots::genericAddSpan):
            * heap/MachineStackMarker.cpp:
            (JSC::MachineThreads::removeThreadIfFound):
            (JSC::MachineThreads::gatherFromCurrentThread):
            (JSC::MachineThreads::Thread::captureStack):
            (JSC::copyMemory):
            * interpreter/Register.h:
            (JSC::Register::operator=):
            (JSC::Register::asanUnsafeJSValue):
            (JSC::Register::jsValue):

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r188067.

    2015-08-06  Filip Pizlo  <fpizlo@apple.com>

            Structures used for tryGetConstantProperty() should be registered first
            https://bugs.webkit.org/show_bug.cgi?id=147750

            Reviewed by Saam Barati and Michael Saboff.

            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::tryGetConstantProperty): Add an assertion to that effect. This should catch the bug sooner.
            * dfg/DFGGraph.h:
            (JSC::DFG::Graph::addStructureSet): Register structures when we make a structure set. That ensures that we won't call tryGetConstantProperty() on a structure that hasn't been registered yet.
            * dfg/DFGStructureRegistrationPhase.cpp:
            (JSC::DFG::StructureRegistrationPhase::run): Don't register structure sets here anymore. Registering them before we get here means there is no chance of the code being DCE'd before the structures get registered. It also enables the tryGetConstantProperty() assertion, since that code runs before StructureRegisterationPhase.
            (JSC::DFG::StructureRegistrationPhase::registerStructures):
            (JSC::DFG::StructureRegistrationPhase::registerStructure):
            (JSC::DFG::StructureRegistrationPhase::assertAreRegistered):
            (JSC::DFG::StructureRegistrationPhase::assertIsRegistered):
            (JSC::DFG::performStructureRegistration):

2015-08-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r189012. rdar://problem/22084478

    2015-08-26  Saam barati  <sbarati@apple.com>

            MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
            https://bugs.webkit.org/show_bug.cgi?id=148500

            Reviewed by Mark Lam.

            Consider the following scenario:
            - On OS X, WTF::pageSize() is 4*1024 bytes.
            - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
            - sizeof(MarkedBlock) == 248
            - (248 + 53000) is a multiple of 4*1024.
            - (248 + 53000)/(4*1024) == 13

            We will allocate a chunk of memory of size 53248 bytes that looks like this:
            0            248       256                       53248       53256
            [Marked Block | 8 bytes |  payload     ......      ]  8 bytes  |
                                    ^                                      ^
                               Our Environment record starts here.         ^
                                                                           ^
                                                                     Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.

            We need to ensure that we round up sizeof(MarkedBlock) to an
            atomSize boundary. We need to do this because the first atom
            inside the MarkedBlock will start at the rounded up multiple
            of atomSize past MarkedBlock. If we end up with an allocation
            that is perfectly aligned to the page size, then we will be short
            8 bytes (in the current implementation where atomSize is 16 bytes,
            and MarkedBlock is 248 bytes).

            * heap/MarkedAllocator.cpp:
            (JSC::MarkedAllocator::allocateBlock):
            * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
            (use):
            (makeFunction):

2015-07-31  Lucas Forschler  <lforschler@apple.com>

        Merge r187579

    2015-07-29  Filip Pizlo  <fpizlo@apple.com>

            DFG::ArgumentsEliminationPhase should emit a PutStack for all of the GetStacks that the ByteCodeParser emitted
            https://bugs.webkit.org/show_bug.cgi?id=147433
            rdar://problem/21668986

            Reviewed by Mark Lam.

            Ideally, the ByteCodeParser would only emit SetArgument nodes for named arguments.  But
            currently that's not what it does - it emits a SetArgument for every argument that a varargs
            call may pass.  Each SetArgument gets turned into a GetStack.  This means that if
            ArgumentsEliminationPhase optimizes away PutStacks for those varargs arguments that didn't
            get passed or used, we get degenerate IR where we have a GetStack of something that didn't
            have a PutStack.

            This fixes the bug by removing the code to optimize away PutStacks in
            ArgumentsEliminationPhase.

            * dfg/DFGArgumentsEliminationPhase.cpp:
            * tests/stress/varargs-inlining-underflow.js: Added.
            (baz):
            (bar):
            (foo):

2015-07-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r187139. rdar://problem/21847618

    2015-07-21  Filip Pizlo  <fpizlo@apple.com>

            Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner.

            * jsc.cpp:
            (main):

2015-07-23  Lucas Forschler  <lforschler@apple.com>

        Merge r187125

    2015-07-21  Filip Pizlo  <fpizlo@apple.com>

            Fixed VM pool allocation should have a reserve for allocations that cannot fail
            https://bugs.webkit.org/show_bug.cgi?id=147154
            rdar://problem/21847618

            Reviewed by Geoffrey Garen.

            This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of
            the JIT pool is reserved for allocations that cannot fail. It makes sense to make this
            a fraction rather than a constant because each allocation that can fail may cause some
            number of allocations that cannot fail (for example, the OSR exit thunks that we
            compile when we exit from some CodeBlock cannot fail).

            I've tested this by adding a test mode where we artificially limit the JIT pool size.
            Prior to the fix, we had >20 failures. Now we have none.

            * heap/GCLogging.cpp:
            (WTF::printInternal): I needed a dump method on Options members when debugging this.
            * heap/GCLogging.h:
            * jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close.
            * jit/ExecutableAllocatorFixedVMPool.cpp:
            (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing.
            (JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics.
            (JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things.
            * jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool.
            (main):
            (CommandLine::parseArguments):
            (jscmain):
            * runtime/Options.cpp:
            (JSC::OptionRange::dump): I needed a dump method on Options members when debugging this.
            (JSC::Options::initialize): This can now be called more than once.
            * runtime/Options.h:

== Rolled over to ChangeLog-2015-07-23 ==
